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ABSTRACT 


This  report  covers  two  years  of  research  in  a  continuing  program  m 
the  Augmentation  Research  Center  (ARC)  of  tne  Infornation  Sciences 
Laboratory  o£  Stanford  Research  Institute,  supported  oy  arpa  ar.d  RADC 
under  Contract  F30602-6d«C«02a6. 

Some  of  the  work  reported  was  aiso  supported  by  AHPA  and  NASA 

under  Contract  KAS1-Y&97. 

The  research  reported  is  aimed  at  the  development  of  'n-line  computer 
aide  for  increasing  the  performance  of  individuals  ar.d  teams  engaged 
in  intellectual  work,  and  the  development  of  techniques  for  the  use 
of  such  aids.  The  report  covers  hardware  and  software  development, 
applications  in  several  areas  relating  to  management  of  a  community 
of  workers  who  use  on-line  aids  and  to  informatio:  management  for 
such  a  community,  participation  in  tne  AHPA  computer  network,  ano  a 
summary  of  plans  for  the  continuation  of  the  research. 
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The  research  described  m  this  report  represents  conceptual,  design, 
and  development  work  oy  a  large  number  of  peoplej  the  program  has 
been  active  as  a  coordinated  team  effort  since  1963.  The  research 
reported  here  was  a  cooperative  team  effort  involving  tne  entire  ARC 
staff.  ‘The  following  is  an  alphabetical  listing  of  the  current  ARC 
staff i 

Geoffrey  h.  Ball,  Walter  L.  Bass,  Vernon  R,  Baughman,  nary  3. 
Caldwell,  Roberta  A.  Carillon,  David  Casseres,  Mary  bo  Cnurcn, 
William  s.  Duv'll,  Douglas  C.  Engelbart,  William  K.  English,  Ann 
P.  Geoffrion,  Martin  L.  Hardy,  Jared  M.  Harris,  j.  David  Hopper, 
Charles  h.  Irby,  L.  Stephen  Leonard,  John  T.  Melvin,  n.  Lean 
Meyer,  Janes  c.  Horton,  Bruce  L,  Parsley,  William  H.  Paxton,  ja<e 
Ratliff,  Barbara  E.  Row,  Martha  E.  Tru.ndy,  Edward  K*  Van  de  Riet. 
John  M#  Yarborough. 

The  following  former  ARC  staff  members  also  contributed  to  tne 
research i 

Donald  I.  Andrews,  Roger  D.  Bates,  David  A.  Evans,  Stephen  P. 
Levine,  Stephen  H.  Paavoia,  Helen  H.  Prince,  Jons  T .  kulifson, 
Elmer  B.  Shapiro,  F.  K.  Tomlin. 
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TECH;!  I  CAL  EVALUATION 


The  Augmentat  on  Research  Center  (ARC)  is  a  community  of 
about  28  researchers,  supported  by  several  different  contracts 
since  1963,  in  nich  all  the  research  activity  is  aimed  at 
(1)  exploring  the  possibilities  for  augmenting  the  performance 
of  intellectual  work  with  the  help  of  real-time  computer  aids 
and  (2)  the  xperimental  development  of  computer  aids  and 
augmentation  systems. 

All  the  researchers  within  the  ARC  do  as  much  of  their  work 
as  possible  at  display  consoles  (depending  on  console  avail¬ 
ability  and  whether  a  specific  tasl  can  appropriately  be  done 
at  a  console).  Thus  they  serve  no,  only  as  researchers  but 
as  th?  subjects  for  the  analysis  and  evaluation  of  the  augmenta¬ 
tion  systems  that  they  are  developing. 

Consequently,  an  important  aspect  of  the  augmentation  work 
done  within  the  ARC  is  that  the  techniques  being  explored  are 
implemented,  studied,  and  evaluated  with  tne  advantage  of 
intensive  everyday  usage  within  a  coordinated  working  environ¬ 
ment  that  is  compatible  with  the  particular  techniques  being 
studied.  This  strategy,  called  "bootstrapping,"  is  a  key  con¬ 
cept  in  much  of  the  ARC  design  philosophy. 

The  focus  of  the  augmentation  is  on  "text"  manipulation, 
where  text  is  defined  as  strings  of  characters,  mathematical 
equations,  programming  statements,  line  drawings,  columns  of 
figures,  etc.  A  powerful  net  of  commands  allow  instantaneous 
composition,  editing,  copying,  printing,  analysis,  calculation, 
etc.  through  interaction  via  a  TV  display,  binary  keyset,  key¬ 
board,  and  display  pointing  device. 


The  system  is  successfully  used  at  the  ARC  in  all  phases 
of  daily  activity  including:  program  writing  and  debugging, 
report  preparation  and  printing,  conducting  meetings  and  demon¬ 
stration,  project  management,  note  taking,  etc.  At  least  p3rt 
of  the  success  of  the  system  is  due  to  the  dedication  and  zeal 
with  which  the  ARC  pers  nncl  use  and  develop  it. 


DUANE  L.  STONE 
Technical  Evaluator 
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I  INTRODUCTION 


A*  General 

Thi  Augmentation  Research  Center  (ARC*  is  a  community  of  about  26 
researchers,  supported  by  several  different  contracts.,  in  which 
all  the  research  activity  i*  aimed  at  (1)  explor.  .g  the 
possibilities  for  augmenting  the  performance  of  intellectual  work 
with  the  help  of  real-time  computer  aids  and  (2)  tne  experimental 
development  of  computer  lids  and  augmentation  systems. 

Several  different  coordinated  research  activities  nave  been 
developed,  sponsored  by  different  contracts,  to  pursue  tne  various 
aspects  of  tnis  augmentation  research.  The  ascects  reported  here 
arei 

(1)  Tne  Management  System  Research  Activity,  whicr.  na3  been 
supported  oy  RADC  under  this  contract, 

(2)  The  development,  operation,  and  maintenance  of  a  real-time 
computer-display  system,  including  both  hardware  and  software 
aspects  and  participation  in  tne  ARPA  computer  network 
experiment.  This  nas  been  supported  by  ARPA  and  RADC  under 
this  contract,  and  by  ARPA  and  NASA  under  Contract  NAS1-7927, 
The  facility  is  dedicated  solely  to  the  ARC1*  activities. 

All  the  researchers  within  the  ARC  do  ac  mucn  of  tneir  work  as 
possible  at  display  consoles  (depending  on  console  availability 
and  whether  a  specific  task  can  appropriately  be  done  at  a 
console)  .  Thus  they  serve  not  only  as  researchers  out  as  tr.e 
subjects  for  the  analysis  and  evaluation  cf  the  augmentation 
systems  that  they  are  developing. 

Consequently,  an  important  aspect  of  the  augmentation  work  dene 
within  the  the  ARC  (for  instance,  of  the  RADC-sucported  Management 
Systems  Research)  is  that  tne  techniques  being  explored  are 
implemented,  studied,  and  evaluated  with  the  advantage  of 
intensive  everyday  usage  within  a  coordinated  working  environment 
that  is  compatible  with  the  particular  techniques  being  studied. 

This  strategy,  called  "bootstrapping,”  is  a  key  concept  in  much  of 
our  design  philosophy. 

Q.  On-Line  Aid  Systems  in  the  Augmentation  Research  Center 

This  section  very  briefly  describes  the  two  mador  augmentation 
systems  available  to  workers  in  the  Augmentation  Research  Center. 
These  systems  are  the  On-Line  System  (NLS)  and  tne 
Typewriter-Oriented  Documentation-Aid  System  ITODAS). 

Aopendix  A  is  a  more  complete  description  cf  the  user  features 
cf  these  systems;  the  reader  who  is  not  already  acquainted  «itn 
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ABC's  research  will  find  that  this  appendix  prcviacs  a  useful 
background  for  tne  main  body  of  the  report. 

APDenaix  d  gives  a  detailed  description  of 
NLS/TOUAS  implementation , 

1.  The  On-Line  system  (NLS) 


NLS,  as  currently  implemented,  is  essentially  a  highly 
interactive,  display-oriented  text-manipulation  system. 


inteJJefl  t0  bc  on  a  regular,  mere  or  less  full-tine 

basis  in  a  time-sharing  environment,  by  users  vno  are  not 
necessarily  computer  professional s.  The  practices  ana 

inK52i?UC!  devel°Pe<3  fcy  *9kr§  for  exploiting  NLS  are  is  muen  a 
bject  of  research  interest  i§  the  development  of  NL3  itself. 


a  Structured  Text 


text  handled  by  NLS  is  in  "structured-statement"  form, 
special  formit  is  simply  g,  hierarchical  arrangement  of 
statements, M  resembling  a  conventional  "outline'1  form. 


A  statement  is  simply  a  string  of  text,  of  any  length; 
this  serves  as  tne  basic  unit  in  the  construction  of  the 

^  Etch  paragraph  and  neaaine  in  thi3  document 

is  an  NLS  statement. 


b»  Use  of  the  system 


The  creation  cf  new  text  material  as  content  for  a 
achieved  by  typing  the  new  material  on  a  ke  ooara 
of  several  possible  NLS  commands,, 


file  is 
under  any 


The  study  capabilities  of  NIS  constitute  its  nost  oowerful 
sna  unusual  features,  Tne  following  Is  a  brief,  ccnlei.sed 
description  cf  the  operations  that  are  possioie. 


The  process  of  sovlng  from  one  point  in  an  Nts  file  to 
fn?^:,IrS JHhlf "  corresponds  to  turning  pares  in  nara  copy,  is 
called  Jumping. "  a  very  large  family  of  "Jump"  corn-anas 
allo-.s  tne  user  to  specify  locations  in  the  file  in  a  number 
of  ways  --  e.g.,  by  specifically  identifying  •  statement  or 
by  specifying  a  structural  relationship  to  some  other 
statement. 


The  NLS  content  antlyxer  permits  automatic  searching  of  a 
file  for  statements  satisfying  some  content  pattern 


a 
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specified  by  the  user,  me  pattern  is  written  in  a. 
language  as  part  of  the  file  text. 


special 


A  large  repertoire  oi  editing  commands  is  provided  +or 
modification  of  the  text  in  a  file. 


2.  The  Typewriter-Oriented  Documentation-Aio  system  (iodaS) 

TODAS  is  a  text-handling  system  designed  as  a  "typewriter- 

J'Partj  t0  NLS*  TODAS  Can  oe  operated  from  a  Teletype  or 
y  other  K»nd  of  hard-copy  terminal,  includi rc  terminals 
linked  to  the  timesharing  computer  facility  (an  x.5  9k0 
with  special  hardware)  througn  acoustic  couplers  and  ordinary 
telephone  lines  (as  opposed  to  NLS ,  which  requires  microwave 
transmission  to  achieve  the  necessary  car.dwidth  for  displays). 

3.  output  Facilities 


The  facility*  for  producing  hard-copy  output  fron  NLs/Tujas 

fnie?*ln5;1Ude  *  Une  prirUera  *  paper-tape-driven  typewriter, 
and  the  Oraphics-oriented  Document  Output  System  (oqdoS). 


The  line  printer,  because  of  its  speed  of  operation,  is  the 
routine  means  of  producing  hard  copy  for  use  within  ARC  TT 
is  used  heavily  ny  all  NLS/TCDAS  researchers. 


The  paper-tape  typewriter  is  used  for  producing 
report-quality  typing,  such  as  this  report.  As  it  is 

*low  *ml  inconvenient,  it  is  not  normally  use 
except  for  final  output  of  material  tc  oe  nublished. 


d 


OODOS  produces  magnetic  tape  which  is  then  turned  over  to  a; 

facility  where  it  is  run  on  Stromoerg-Carlson 
microfilm  equipment  to  produce  frames  of  microfilm  (e*' 
m.crofiche)  corresponding  to  pages  of  full-size  hard  copy. 

0i  ttiis  aysten  tnat  H  handle  drawings 
Produced  in  NLS  files  by  means  of  the  NLS  graphics 

capability.  G0D03  is  still  in  the  experimental  stage  am 
has  not  been  used  extensively. 


k.  This  Report  as  an  Example  of  NLS/TODAS  Capability 


The  following  discussion  may  be  taxer*  as 
indication  of  the  power  of  nls  and  TODAS 
specific  proDiem  --  namely,  the  writing, 
production  of  this  report. 


a  very  rough 
as  applied  to 
editing,  anc 


a 


sinrie 


The  above  descriptions  of  nls  and  ipdas  were  produced  tv 
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notification,  using  NL3 ,  of  the  more  detailed  descriptions  in 
Appendix  A. 

The  entire  task  cf  notification,  including  formatting, 
insertion  into  the  body  of  the  report,  ana  a.\l  other 
details,  required  about  half  an  hour  of  work  by  an  NLS  user 
who  was  already  familiar  with  the  contents  of  the 
descriptions ,  if  the  joo  had  been  done  by  someone  who  was 
not  familiar  with  the  material  (but  who  waa  familiar  vitn 
NLS)  it  might  have  taker,  fifteen  minutes  longer. 

The  original  description  was  written  for  an  earlier  report 
and  then  kept  available  as  an  NLS/TODAS  file  in  anticipation 
of  future  opportunities  for  using  it. 

Indeed;  a  considerable  amount  of  the  material  in  this  report 
was  devel  ’'ped  by  modification  of  existing  filec,  and  we  may 
expect  the-  new  material  generated  for  tnis  report  to  continue 
in  use  as  a  collection  of  NLS/TODaS  files  f  o’*  as  long  a  a  it  can 
be  updated  to  reflect  curren*  reality. 

TODAS  was  used  or imarily  for  the  task  of  entering  new 
material  into  on-line  files,  considerable  portions  of  the 
material  were  put  on  line  by  a  secretary  using  TODAS, 
working  from  handwritten  material  and  from  recorded 
dictation,: 

Finally,  we  may  note  that  the  writing  of  this  report,  using  NLi 
and  TODAS  throughout,  was  achieved  under  considerable  time 
pressure  by  a  team  consisting  cf  about  a  dozen  people,  all  of 
whom  were  doing  other  important  work  at  tne  same  time. 
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II  MANAGEMENT  SYSTr! 


Our  Management  System  Research  Activity  nas  involved  three  *a.1or 
areas  of  concentration.  In  practice  these  areas  overlap 
considerably,  so  tnat  there  is  an  integrated  research  effort  or  ran v 
phases  of  management  technique  and  theory  that  incinge  uror  the 
operation  of  AFC,  Kor  purposes  of  description,  however,  ve  disc-  s 
each  area  of  concentration  aa  if  it  were  an  independent  effort. 

The  three  areas  are: 

(1)  Management-information  Operation*  --  research  on  techniques 
for  using  management  information  in  the  ArC  environment,  including 
the  development  of  computer  aids  for  the  storage  and  manipulation 
of  such  information 

(2)  Organization  St.uaies  --  research  or  the  A-iC  on-line  community 
of  workers  and  experimentation  vitn  organization  structure  and 
planning  methods  m  the  on-line  community 

U)  Team  Augmentation  ana  Dialogue  support--  research  cm. 
augmenting  a  team  or  community  of  intellectual  vorxers  cy  •'earns  of 
systems  that  support  the  intellectual  dialogue  of  the  team. 

A.  Management-information  operations 

1.  introduction 

In  accordance  with  ou»*  usual  strategy,  ve  have  pursued  our 
inveatlgaticn  of  management-information  operations  oy  jsmz 
and  TODmS  to  develop  and  provide  aids  for  management  of  tne 
on-line  community. 

There  are  many  areas  of  potential  application  for  on-line  aids; 
we  i.ave  chosen  those  which  appear  to  pe  rut  useful 
operationally  for  experiments  with  the  development  of  on-line 
Rids . 

This  section  gives  detailed  descriptions  of  several 
amplications  that  have  been  developed,  illustrated  with 
photographs  of  the  NLS  display  screens  tc  snow  sequences  of 
information-manipulation  operations,  a  familiarity  with  the 
basics  of  NLS  is  assumed;  Appendix  a  is  intended  to  provide  tie 
necessary  information  about  nls. 

in  following  the  descriptions,  it  is  worth  <eenng  in  mind  that 
the  speed  with  which  N  I.  S  serves  its  users  is  an  important  part 
of  its  utility.  The  onotograpns  indicate  transitions  that 
normally  take  only  or.e  or  two  seconds.  This  speed  lena?  great 
power  and  flexibility  tc  the  relatively  sir r*le  service 
functions  performed  bv  NLS , 


5 


Sec .  II 

MANAGEMENT  SYSTEM 


2.  Project  costs 

The  most  obvious  area  for  application  of  on-line  aids  to 
Management  within  ARC  i®  project  cost  accounting,  considerable 
worn  has  been  done  on  the  development  of  several 
cost-information  files  and  c  techniques  for  their  use, 

a.  Cost  Records 

The  institute's  accounting  system  provides  ARC  witn  detailed 
cost  records  for  trie  various  "SKI  projects"  (i.e., 
individual  contracts)  being  carried  out  in  ARC, 

The  primary  inputs  to  SRl's  system  are  (1)  weekly  time 
cards  reporting  hourly  charges  to  various  projects  cy 
individual  staff  members,  and  (2)  non-labor  costs  cnargea 
directly  to  projects,  including  actual  charges  to 
projects,  and  commitments  (uncompleted  orders). 

For  each  SRI  project,  the  accounting  system  computes 
dollAr  costs  baaed  on  actual  salary  data  for  each  staff 
member's  hours  charged,  adds  payroll  burden  and  overhead 
amounts  at  current  rates,  combines  these  coats  with 
non-labor  totals,  adds  appropriate  fees,  and  totals  all 
such  charges  each  week  on  a  cumulative  basis. 

Current  charges  are  reported  to  ARC  each  week  on  the 
Project  Status  Report. 

we  need  frequent  and  rapid  access  to  project  cost  summary 
data  for  operational  use,  with  less  reference  to 
lower-level  details,  except  as  the  costs  are  first 
checked  for  reasonableness  and  accuracy.  Therefore  we 
decided  to  start  by  putting  summary  data  on-line  at  arc. 
At!  needed  in  the  future,  we  can  add  more  levels  of 
detail. 

File  HISCC 

We  first  constructed  a  cost-history  file  for  1965-1969 
cost®  on  SRI  projects  ESU  7101  (RADC  contract 
F30602-5S-C-02&6)  and  ESU  7079  (NASA  Contract  NAS 
2.-76975  .  This  file  is  called  HISCO. 

We  decided  that  the  elements  of  HISCO  would  include  tne 
following  for  ea-h  of  the  two  projects,  on  the  baste  of 
l-week  accounting  periods  (as  used  ov  SRI'e  accounting 
system) : 


6 


sec.  II 

MANAGEMENT  SYSTEM 


U)  hal&ry 

(b)  Burdu n 

(c)  overhead 
(cl)  vot-al  cc«t 

(e)  Vee 

(f)  Total  charges. 

See  Figs.  11-1,  II-2,  and  II-3.  Each  of  these  figure! 
shows  a  dismay  of  one  branch  of  the  file,  containing 
the  information  for  a  specific  project  and  year. 

We  alio  needed  a  aection  showing  combined  salary  costs 
and  combines  total  charges  for  all  of  our  projects 
(see  Tlgs,  II-U  and  I 1-5 ) •  We  put  these  costs  in 
septv ate  Branches  of  the  file.  The  last  branch  shows 
total  costs  for  botn  projects  combined,  we 
retroactively  studied  existing  records  for  all  1966 
d&tfc  and  Kept  up  tne  1969  costs  every  a  weeks, 
entering  tr,e  new  data  by  hand. 

We  experimented  with  the  use  of  graphic  representations 
by  entering  charts  in  rildCG.  These  charts  snowen  the 
cumulative  cast  trends  for  each  project  in  a  separate 
branch  of  the  file, 

we  established  links  between  tabular  data  and  cnart 
projections.  This  mads  it  quite  easy  to  refer  to  both 
formats  alternately. 

The  use  of  graphics  in  HISCO  rave  some  indication  of 
the  usefulness  of  such  linking,  out  the  existing 
package  has  limitations  in  the  form  of  a  few  curs  and 
capacity  that  mokes  its  use  of  marginal  value,  work  is 
currently  under  way  to  improve  this  capability,  we 
also  need  local  hard-copy  output  to  maxe  these 
features  of  real  value. 

KIScc  was  a  testing  ground  for  the  first  version  of  the 
NLS  calculator  package,  as  the  file  was  updated,  cost 
data  were  entered  into  new  statements,  and  tne  calculator 
was  used  to  check  the  cost  data  and  to  determine  the 
total  arc  project  costs. 
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FIGURE  IM  A  BRANCH  OF  FILE  HISCO 
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FIGURE  II-?  A  BRANCH  OF  FILE  HISCO 
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FIGURE  11-5  A  BRANCH  OF  FILE  HISCO 


FIGURE  11-6  INITIAL  VIEW  OF  FILE  HISCO 
UPON  ENTRY  VIA  LINK 
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Tnia  employed  tne  ALL,  sUbTr.M'’T,  MULTIPLY  and  1.  V I L 1 
capabilities  and  used  the  four  holding  registers. 

The  calculator  package  Has  an  'INSERT'  conrna  mat 
Inserts  tne  current  contents  of  the  calculator's 
accunulator  into  the  file  text  as  indicated  cy  a  tne 
selection.  Wont  wit:.  HISCO  indicated  tnat  a  'replace' 
command  would  oe  very  desiraole. 

Ifte  usual  way  of  accessing  HISCO  was  via  pre-es ta bl is ne  i 
links  Iron  other  working  files  whenever  the  user  nad  a 
question  about  recent  costs.  Tne  vif-’SPECs  in  tne  lin< 
usually  caused  HISCO  to  be  brought  in  with  only 
high-level  statements  on  display,  snowing  only  tne 
headings  for  project  name,  combined  salary,  total 
charges,  and  total  APC  costs  (see  Fie,  11-6} . 

The  user  could  then  select  tne  project  ne  was 
interested  in  (oy  the  command  jun?  To  ITEM)  open  uo  an 
additional  level  for  viewing,  ana  see  column  headings 
and  numerical  data  (Figs.  II-l,  1 1 - 2 ,  ana  II-3). 

Then  he  could  .jump  down  through  the  accour.tine 
periods  to  the  one  ne  was  locking  for. 

If  he  was  making  a  calculation  (pernaps  already 
started  in  the  file  he  was  working  m  before  he 
linked  to  HISCO),  ne  could  tnen  calx  tne  calculator 
and  add,  subtract,  multiply  or  divide  oy  anv  of  tne 
numoers  in  HISCO.  His  previous  calculations  while 
in  the  previous  file  would  remain  intact. 

If  finished  with  HISCO,  he  couli  then  return  to  tr.e 
previous  file  (by  the  command  JUMP  To  Fin  return, 
and  continue  with  the  calculation,  having  found  m 
HIPCC  the  input  number  or  numbers  he  was  looking 

for. 

Such  a  sequence  occurs  very  fast,  experience  with 
HISCO  seems  to  prove  the  value  of  having  a  simple 
calculator  built  into  NLS ,  where  it  is  instantly 
available  when  reeded  and  can  interact  directly  with 
data  m  an  NLS  file. 

Desk  calculators  are  available  for  most  ceonie  wr.p 
need  to  do  basic  arithmetic  work,  but  v her.  one  is 
looking  through  extensive  i* \e#  for  inputs  tc 
calculations,  the  conventional  calculator  is  net 
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nearly  as  uaefu?  as  this  on-line  version. 

Summary:  Aa  an  arena  for  experimentation,  HISCO  proved 

very  valuable.  Operationally,  it  was  useful  from  time  to 
time  but  revealed  a  need  fc  more  frequent  uedatim  of 
the  summary  data.  Our  experience  with  HISCO  led  to  the 
development  of  a  redesigned  cost-history  file  called 
COSTS . 

rile  COSTS 

This  file  is  updated  weekly,  with  k-w eek  and  cumulative 
summaries . 

Th^  COSTS  file  is  referred  to  frequently,  because  the 
weekly  inputs  now  show  trends  with  considerable 
sens itivity . 

We  decided  that,  the  elements  most  useful  to  us  for  this 
year  are  the  following:: 

(a)  salary  costs 

(b)  Total  personnel  costs 

(c)  son-labor  costs 

(d)  Total  cost# 

(e)  Total  charges  with  fee 

(f)  Balance  remaining 

See  rigs.  II-?,  I I and  II-$.  Figures  II-7  and  Il-d 
show  the  same  branch  of  tne  file  with  different 
VI EWS  PEC  a  j  Fig.  Il-d  displays  one  more  level  than  rig. 
II-7,  and  this  level  showe  me  weekly  data.  Figure 
II-S  snows  tne  weekly  data  for  another  project. 

We  also  decided  to  include  funding  information  shoving 
current  total?,  unfunded  totals,  and  total  contract 
amounts  in  the  categories  cost,  fee,  and  total. 

we  use  separate  oranchea  for  each  project  and  for  total 
AKC  project  costs  iFi*.  11-10).  The  skeleton  format  for 
the  file  waa  set  up  in  advance  for  the  entire  year  of 
1970. 
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FIGURE  l!-7  A  ORANCH  OF  FILE  COSTS,  SHOWING 

ENTRIES  FOR  4-WEEK  ACCOUNTING  PERIODS 
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FIGURE  11-8  SAME  AS  FIGURE  11-7,  BUT  EXPANDED 
TO  SHOW  WEEKLY  ENTRIES 
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FIGURE  11-9  SAME  AS  FIGURE  !l-8.  BUT  FOR  A 


DIFFERENT  BRANCH  OF  FILE  COSTS 
SHOWING  DATA  FOR  A  DIFFERENT 
PROJECT 


FIGURE  11-10 


A  BRANCH  OF  FILE  COSTS  SHOWING 
COMBINED  DATA  FQR  ALL  ARC  PROJECTS 
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our  approach  wao  to  create  a  separate  statement  for 
<**ch  week,  one  level  below  the  "total"  statements  for 
each  k-week  period.  For  the  second  week  of  1970 
(which  la  in  the  first  accounting  Deriod)  the 
statement  start#  with  a  2-1  and  then,  proceeding 
across  the  line,  shows  the  amounts  listed  above  in  six 
columns  (Tics.  I I -6  and  II-9). 

Before  entering  any  actual  data,  tne  first  top-level 
branch  (containing  some  70  statements)  was  copied 
within  the  file  at  the  same  level  four  or  five  times. 
Then  each  blank  branch  simply  had  the  project  name 
headings  inserted  for  the  project  using  that  branch. 
We  keep  one  extra  blank  format  branch  available  in 
case  any  new  projects  should  arrive. 

Like  HISCO,  COSTS  is  usually  reached  throutn  a  link  from 
some  other  working  file,  perhaps  while  a  study  of 
near-future  coats  is  in  progress,  or  from  an  ongoing 
proposal  cost  estimate.  Again  t-he  file  is  usually 
entered  with  only  the  top-level  statements  or  project 
headings  showing  (see  Fig.  II-ll). 

If  a  particular  project  is  of  interest,  that  orancn  is 
selected  and  another  level  opened  for  view.  The 
second  level  snows  period-by-period  subtotals  in  each 
cost  category  (rig.  II-7).  If  weekly  data  are 
desired,  another  level  is  opened  by  changing  the 
VIEVSPECa  (Fig.  II-o)  and  a  particular  week  i.i 
selected  by  the  command  JUMP  TO  item. 

The  statement  for  each  wee<  has  the  weex  ending 
date  as  its  name.  The  reason  for  this  is  not  only 
so  that  the  statement  for  a  particular  week  can  be 
accessed  by  the  JUMP  TO  NAME  command  using  the 
ending  date,  but  aiso  so  that  the  date  may 
optionally  be  suppressed  from  the  display,  kls  nas 
the  capability  of  suppressing  all  statement  names 
fron  the  display. 

The  normal  way  of  looking  at  the  file  is  with 
names  suppressed;  thus  the  dates  do  not  clutter 
the  display;  however,  a  user  who  needs  tc  know 
the  ending  date  for  a  particular  week  can  see  it 
by  executing  a  single  command. 

To  access  the  information  for  another  project  within 
COSTS,  one  executes  JUMP  TO  hi  TUSH  twice  to  see  the 
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DIFFERENT  VIEWSPECs  TO  SHOW  CONTENT 
ANALYZER  PATTERNS  STORED  'N  FIRST 
STATEMENT  OF  PILE 
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top-level  statement*  again  (Fig.  Il-ll), 

One  can  move  very  quickly  and  accurately  through  a  file 
that  is  »et  up  in  this  fashion,  even  without  any 
familiarity  with  tne  information  it  contain-. 

The  primary  function  of  COSTS  is  to  snow  a  consistent 
week-by-veek  progression  of  costs  for  each  project  py 
category.  The  file  can  also  be  used  for  study  purposes, 
tnrough  the  use  of  content-analyzer  patterns,  some  of 
which  are  stored  In  the  header  statement  (see  Fig,  11-12, 
wnich  is  the  same  as  Fig.  11-11  but  with  different 
YIEWSPECs),  Any  other  patterns  can  te  created  as  needed. 

This  allows  a  user  to  extract  special  categories  of 
information  from  the  file  very  quickly.  For  example, 
a  user  nay  easily  create  a  display  showing  all  project 
costs  for  the  eighth  week  of  1*70,  for  eacn  ARC 
project.  It  is  also  possible  to  output  sucn  a 
"filtered'’  display  via  a  lire  printer,  tnus  obtaining 
hard  copy  of  a  special-purpose  extract  from  the  total 
file. 

The  content  analyzer  is  helpful  when  u*im  the  calculator 
on  all  the  data  for  one  weex,  project  by  project,  to  fine 
total  ARC  charges  by  category. 

When  only  one  week's  data  are  displayed,  one  can  add 
items  down  each  column  ana  insert  the  answer  m  the 
"ARC  total"  space,  one  can  tnen  elear  tne 
accumulator,  ano  add  down  the  next  column,  inis  is 
done  very  rapidly  tnrough  bug  selection  oi  input 
numbers  and  keyset  entry  of  commands  --  ADD,  ADD,  ADD , 
ADD,  INSERT,  CLEAR,  \DD,  ADD,  ADD,  ADD,  INSERT,  CLEA^, 
and  so  forth. 

rigures  11-13  and  Il-lk  are  before/after  bhotos  of 
this  process. 

The  COSTS  file  is  now  operationally  useful  to  us,  and  we 
expect  it  to  be  useful  for  future  experimentation  with 
automatic  processing  techniques, 

b.  Estimates 

proposals 

another  use  of  the  system  is  in  creating  proposal  cost 
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VIEW  OF  FILE  COSTS  WITH  CONTENT 
ANALYZER  IN  OPERATION,  SHOWING  DATA 
FOR  ONLY  A  S'NGLE  WEEK.  This  is  done  by 
using  the  first  pattern  appearing  in  square 
brackets  in  FIGURE  11-12. 
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estimate#,  rfe  first  estimate  trie  amount  of  effort 
required  xor  the  proposed  work.  To  estimate  the  cost  of 
this  effort,  we  make  reference  to  various  on-line  files. 
The  sstiMatin*  process  typically  proceeds  along  the 
i oilowinj  lines. 

Personnel  costs 

The  estimator  loads  a  special  file,  maintained  oy 
himself,  which  is  a  directory  to  all  of  his  other 
files  and  perhaps  to  a  few  files  belonging  to  other 
people.  Figures  11-15  and  11-16  are  two  displays  of  a 
user’s  file  directory.  In  Fig.  11-15,  only 
first-level  statements  are  shown;  these  are  used  for 
establishing  categories.  In  Fig.  II-lo,  another  level 
is  shown,  containing  the  actual  directory  listings  In 
each  category. 

This  "file  directory"  contains  links  to  each  of  tne 
files  that  it  lists,  in  the  present  case  the  files 
probaoly  would  be  coat  histories,  Personnel 
listings,  previous  special  studies  of  costs,  and 
other  administrative  information. 

He  loads  a  previous  cost  estimate,  makes  a  working 
copy  of  it,  chances  the  heading  to  reflect  tne  name  of 
the  new  proposal  estimate,  and  eliminates  the  amounts 
from  the  old  estimate. 

This  produces  a  blank  cost  estinate  format,  if  any 
items  from  the  old  estimate  are  inappropriate,  they 
are  easily  deleted;  new  items  are  easily  added  as 
separate  statements,  when  the  format  ic  ready,  it 
is  output  as  a  new  file. 

He  can  tnen  load  a  file  that  lists  names  of  people  in 
the  croup  and  some  projection  of  expected  additions. 
Figures  11-17,  II-lo,  and  11-19  snow  portions  uf  sjch 
a  file. 

Using  this  personnel-listing  file,  he  obtains 
information  about  labor  categories,  a  branch 
containing  content-analyzer  patterns  is  Kept  in  the 
file.  These  can  be  easily  reached  by  jumping  to  a 
link  which  causes  all  the  patterns  to  be  displayed 
(Fig.  i:-20), 

Eacn  pattern  will  select  some  particular 
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FIGURE  11-15  VIEW  OF  A  USER'S  FILE  DIRECTORY, 

SHOWING  FIRST-LEVEL  STATEMENTS  ONLY 
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FIGURE  11-17  PART  OF  A  FILE  CONTAINING  INFORMATION 
ON  ARC  PERSONNEL.  Not  all  levels  are  shown. 


FIGURE  11-18  A  VIEW  OBTAINED  BY  JUMPING  TO  ONE  CF 
THE  STATEMENTS  SHOWN  IN  FIGURE  11-17 
AND  OPENING  AN  ADDITIONAL  LEVEL 


•i/nm  itM. 


FIGURE  11-19  A  VIEW  OBTAINED  BY  JUMPING  TO  THE  LAST 
STATEMENT  SHOWN  IN  FIGURE  11-18.  WITH 
NO  CHANGE  IN  VIEWSPECs 


FICURE  11-20  COM TFN  r  ANALYZER  PATTERNS  STORED  IN 
T HI  PI  HSONNEL  -INFORMATION  FILE.  Each 
set  of  square  brackets  contains  one  pattern,  used 
to  search  lor  hidden  '  tags’'  in  statements  in  the 
file 
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category  of  statements  from  the  file,  lor 
example,  the  estimator  will  need  to  Know  which 
people  have  the  statu#  of  Senior  Prof essional- 

Ke  selects  the  appropriate  pattern  with  the 
command  EXECUTE  CONTENT  ANALYZER,  and  then 
jumps  on  a  link  which  turns  on  the  content 
analyzer,  starting  the  search  at  the 
beginning  of  the  branch  containing  personnel 
listings  and  restricting  the  search  to  that 
branch. 

This  produces  a  display  snowing  only  the 
listing  of  senior  professionals  ir  tne  groupr 
This  set  of  statements  can  then  be 
transferred  to  tne  new  proposal  cost  estimate 
file. 

Other  patterns  can  be  used  to  extract  sets  of 
statements  according  to  other  criteria  --  for 
example,  all  the  hardware  or  software  people 
in  the  group  (Figs.  11-21  and  11*22). 

Thus  tne  estimator  can  select,  by  labor  category, 
representative  people  who  may  be  involved  with  the 
proposal;  as  he  selects  them,  he  can  transfer  their 
names  and  the  information  that  goes  with  then  to  the 
file  where  he  is  building  up  his  estimate. 

At  present  we  do  not  keep  individual  salary 
information  on  line,  although  we  could  do  this  if 
we  added  some  security  measures.  Calculations  for 
the  average  salary  category,  based  on  the  specific 
people  contemplated,  are  made  off-line  at  present. 

Tneae  average  salary  amounts  ire  inserted  into  the 
on-line  cost  estimate.  The  calculator  is  used  to 
multiply  nunDers  of  man-months  times  average 
salaries  per  me  ith  to  determine  total  salary  costs 
per  labor  category  and  overall  direct  labor  totals,. 
All  of  this  is  achieved  w?thin  the  actual  file  that 
will  oe^ome  the  finished  estimate. 

Tne  payroll  bur  en  and  overhead  rates  are  checked  for 
currency  and  ir.ierted  into  tne  estimate,  using  tne 
calculator  to  apply  them  to  the  direct  labor.  At  this 
point  the  labor  portion  of  the  estimate  ij  completed. 
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FIGURE  11-21  VIEW  DET  AINED  BY  USING  CONTENT 
ANALYZER  TO  SELECT  ENTRIES  IN 
PERSONNEL-INFORMATION  FILE  THAT 
ARE  TAGGED  FOR  "HARDWARE" 


FIGURE  W-22  VIEW  0  ,iNED  BY  USING  CONTENT 
ANALYZER  TO  SELECT  ENTRIES  IN 
PERSONNF  L-IN  FORMA  T*ON  FILE  THAT 
ARE  TAGGED  FOR  "SOFTWARE" 
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Non-Labor  Coat* 

A  typical  estimate  will  involve  sons  travel  cost*, 
some  ccnaultant  coats,  and  *one  resort  coats.  Data 
supporting  the  cost  of  consultants  nay  be  checked  oy 
reviewing  current  consultants '  costa  oy  project  and  oy 
consultant.  These  are  Kept  in  a  separate  file  and 
reached  tnrough  a  link  for  review.  The  data  nay  oe 
copied  into  the  estimate  if  some  of  the  information  is 
of  use. 

Report  production  cost3  are  estimated  using  current 
Institute  schedules,  which  are  based  primarily  on  the 
number  of  pages  expecteo  m  the  end  product.  These 
computations  can  be  made  using  the-  calculator,  and  tne 
existing  cost  factors  from  tr.e  last  proposal,  checked 
for  current  apclicaoility. 

in  addition,  there  may  oe  plans  to  add  equipment  in 
the  proposal,  in  this  case,  the  estimator  will  use  an 
equipment  study  written  in  another  file  by  the  people 
involved  m  hardware  design. 

The  equipment  coats  contained  in  the  special  study 
are  summarized  in  total  and  reached  by  a  link.  The 
special  study  can  be  viewed  and  updated  as 
appropriate  and  can  pe  copied  to  eo  with  the 
proposal  as  an  appendix  or  used  later  for  back  up. 

in  this  fashion,  various  information  is  gathered  from 
various  files  and  transferred  intc  the  developing  cost 
estimate,  rigures  11-23,  II-H,  and  IX-25  show 
various  portions  of  a  completed  on-line  cost  estimate 
as  actually  used  for  a  recent  AKC  proposal. 

Working  forecasts 

Operational  use  of  Estimates 

As  the  project  progresses,  proposal*  and  estimates  can 
also  be  used  as  guides  for  management  of  the  project. 

is  useful  to  forecast  tne  expected  project  coats  on 
either  a  four-week  period  or  monthly  basis. 

This  can  be  dene  by  creating  a  new  file  using  the  type 
of  format  that  the  COSTS  file  uses,  we  insert  total 
figures  from  the  curt  estimate,  using  the  calculator 
to  determine  average  rates  and  specific  eatinatej 
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amounts,  and  insert  answers  into  the  file  as  it 
bulls?.  This  month-ty-month  estimate  can  be  reaches 
through  a  link  from  working  cost  files,  from  the 
original  estimate,  or  any  other  file  where  the 
question  of  monthly  estimated  project  costs  nay  arise. 

c.  Purchase-order  Processing 

in  miking  an  estimate  of  costs  for  new  equipment  being 
constructed  at  ARC,  reference  to  previous  cost  information 
is  very  useful,  we  have  constructed  a 

purcnase-order/requisition  processing  file  which  contains  a 
separate  statement  for  eacn  3  ten  purchased  for  tnc  past  two 
years  at  ARC.  figure  11-26  shows  a  portion  of  this  file. 

Each  statement  contains  the  following  information  aoout 
each  purchase* 

(1)  Total  price 

This  is  entered  as  the  statement  name. 

At  present  this  is  not  used  as  an  NLS  name,  but  as  a 
way  of  eliminating  information  from  the  screen  at 
will,  keeping  a  consistent  location  in  columnar  form 
for  such  totals. 

(2)  Description  of  item 

(3)  Vendor 

U)  Number  of  units  purchased  and  price  per  unit 
(3)  Purchase  Requisition  number 

(6)  Date  requisition  sent 

(7)  Purchase  order  number  when  order  is  placed 

(8)  Date  crder  is  placed 

(9)  Project  or  account  charged 

(10)  Date  order  is  received 

(11)  When  the  order  i*  completed,  it  is  marked  with  the 
special  code  *compr.  This  can  oe  detected  by  a 
content-analyier  pattern. 
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Ail  outstanding  order*  are  contained  at  a  second  level  under 
a  single  branch  (see  Fig,  11-27))  therefore  the  distinction 
between  outstanding  and  completed  orders  is  easy  to  see  just 
by  reference  to  level.  To  reduce  clerical  error,  we 
consider  an  order  completed  when  the  »comp*  pattern  is 
inserted  and  tne  statement  is  moved  to  its  alpruoetical 
position  on  the  top  level. 

This  file  can  be  searched  using  the  content  analyzer  in  some 
interesting  way*,  we  can  t*x  for  all  items  purchased  from  a 
particular  vendor  on  any  particular  project  and  see  only 
those.  If  we  wonder  about  the  unit  price  of  a  thermal  wire 
stripper,  model  2W-1,  we  can  quickly  get  that  information. 

If  we  wonder  what  we  purchased  on  PP  A06927,  that  comes 
simply  by  executing  a  content  analyzer  pattern  ap-<*ifying 
the  number.  We  can  see  *11  outstanding  orders  charged  to  a 
particular  project  quickly,  Figure  11-28  snows  a 
content-analyzer  pattern  that  has  been  temporarily  written 
into  the  file,  for  finding  any  entries  pertaining  to  orders 
for  relays  under  Project  7101.  r'igure  11-29  shows  s.  view 
generated  by  usine  this  pattern. 

This  file  is  useful*  then,  from  a  project-administration 
standpoint,  from  the  standpoint  of  following  a  purchase 
requisition  from  the  order  stage  through  completion,  and 
also  for  providing  backup  information  for  cost  estimates. 

This  file  can  also  be  used  as  a  tickler  file  by  inserting 
a  pattern  in  the  "outstanding  requisi tiona"  branch  which 
shows  tne  date  we  feel  we  should  follow  up  on  tne  order. 
Each  day  one  can  ask  for  all  those  items  tnat  have  the 
current  date  as  a  follow-up  date. 

This  file  is  kept  up-to-date  by  the  secretary  of  the 
hardware  group,  who  is  most  involved  with  requisitioning . 

Sfca  does  this  updating  entirely  with  TODAS. 

d.  Summary  on  the  systematic  Use  of  project  Cost  Tiles 

One  by  one  eacn  of  these  files  might  be  interesting.  As  a 
combination,  quickly  available  to  many  users,  their  utility 
seems  remarkable. 

A  cost  study,  as  discussed  above,  can  rely  on  til 
previous  project  coats  as  recorded  in  the  system  and  can 
draw  on  those  files  for  inputs.  One  can  ^raw  q;,  the 
personnel  roster  file  by  labor  category,  work  interest  or 
as  extended  into  a  skills  inventory. 
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FIGURE  11-29 


VIEW  GENERATED  BY  A  SEARCH  ON 
PATTERN  SHOWN  IN  FIGURE  11-28 
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We  an  Drowse  through  tne  purchase-order  fj'e,  reflecting 
the  current  or  previous  coats  per  iten.  wt  can  link  to 
activity-planning  flies  to  see  wnicn  people  are  involved 
with  various  ongoing  tasks  and  to  see  on  vnat  tasks  ve 
are  contemplating  certain  equipment  purchases.  «e  can 
link  to  proposal  cost  estimates  for  mcnth-by-month  cost 
projections. 

These  files  can  be  accessed  in  any  order,  from  any 
direction,  at  any  time,  vitn  only  a  few  keystrokes  oy  the 
user.  They  are  also  accessible  remotelv  through  tne  use  of 
TODAS,  thereby  giving  nobility  to  the  user  with  less  load  on 
the  system. 

Our  main  objective  in  making  cost  studies  is  to  arrive  at 
solid  sets  of  projections  or  other  answers  as  quickly  and 
effectively  as  possible.  Direct  on-line  access  to  nput 
information  is  extremely  nelpful. 

3.  Activity  Planning  ana  Status 

a.  Introduction 

Section  11*3-2  describes  the  experimental  establishment  of  a 
TODAS  Development  Activity  and  discusses  its  method  of 
operation.  One  facet  of  TODAS  work  is  the  extensive 
experimental  use  of  on-line  files  as  aids  in  conducting 
meetings  and  formulating  plans.  This  section  gives  some 
details  on  the  construction  and  use  c-f  these  files. 

b.  Planning  and  Status  Files  for  TODAS  Develooment  Activity 
Tile  UPLAN 

The  planning  file  for  the  TODAS  Development  activity 
contains  a  branch  fcith  comments  on  now  to  use  the  t*ie,  a 
branch  for  content-analyxer  patterns-  and  a  branch 
comtaining  actual  task  plans. 

The  task-planning  branch  has,  as  substatements,  task 
categories  which  include  documentation  plana,  teaching 
plans,  design  plans,  MtTA  plans,  and  inactive  task 
plans,  The  levels  under  these  categories  contain 
separate  task  plans,  si.cn  as  "TODAS  REFERENCE  GUIDE 
DEVELOPMENT* M  "USER  EXPERIMENTS  RELATED  TO  TODAS,"  and 
"TEXT  MANIPULATION  SYSTEMS  BIBLIOGRAPHY • " 

Eacn  task  branen  contains  comments  oy  the  task 
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leader  on  tne  following: 

(1)  Description  of  tne  tas*,  witn  links  to  otner 
working  files  used  in  :ts  development 

(2)  consents  on  tne  relationship  of  the  tas*  to 
other  ARC  tasKS 

(3)  Estimates  of  ceocle  Involved  (with  levels 
cf  effort  ana  timr.e) 

( k i  status  comments 

UPLAN  is  linked  to  from  anotner  file  called  UrtEil 
(described  below),  vhicn  is  used  for  on-line  note-taking 
during  meetings  of  the  TODAS  group.  Portions  of  UPLAN 
can  be  temporarily  copied  into  UMEET  for  use  during 
meetings . 

DPI, AN  contains  a  blank  task  format  in  a  separate  branch, 
whenever  a  new  task  is  added,  this  ©ranch  is  copied  into 
the  appropriate  planning  area  (such  is  documentation 
plana).  Then  the  name  of  tne  task  is  inserted  as  a 
heading  along  with  the  initials  of  the  task  leader. 

Certain  items  in  this  file  are  useful  in  content-analysis 
searches,  me  most  useful  are  the  initials  of  Deopie 
involved  in  tasks,  the  milestones,  tne  estimates,  and  tr.e 
status,  to  make  content-analysis  searches  more 
consistent,  asterisks  are  placed  before  such  items. 

With  an  appropriate  pattern,  one  can  tnen  as<  a 
question  such  as  "what  is  the  involvement  of  a 
particular  person  in  this  activity?”  task  by  task. 

All  branches  with  estimates  containing  the  specified 
initials  and  an  asterisk  will  then  be  shown.  The  same 
branenes  show  expected  levels  of  effort. 

Since  this  is  the  only  information  displayed  on  the 
screen,  it  is  relatively  easy  to  see  potential 
conflicts  in  the  allocation  of  a  person's  time  between 
tasks  for  this  activity  or  to  na.<e  a  hard  copy  of  this 
displayed  information  on  the  line  nrinter. 

The  content  analyser  can  also  return  statements 
commenting  on  the  status  of  tasks,  sc  that  a  quick  survey 
of  all  such  comments  can  be  made.  This  is  particularly 
useful  for  coordination  of  several  tasks  and  for 
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preparing  for  meetings  of  the  grouD. 


When  many  people  try  to  update  tne  same  file,  serious 
oroblema  are  created.  This  is  a  well-known  situation 
(discussed  further  in  Appendix  B),  If  two  people  are 
both  working  on  the  file,  one  person's  work  nay  oe 
lost  when  someone  else  who  has  been  using  the  file 
writes  his  copy  back  out  on  the  disc.  Therefore  we 
tried  to  introduce  a  convention  where  people  place  a 
signal  of  some  sort  in  the  file  when  it  is  in  use. 

This  procedure  was  not  well  used,  nrobaPly  because 
people  were  generally  in  too  much  of  a  hurry. 
Therefore,  some  work  wae  lost.  We  found  that  it  was 
easier,  with  the  present  file-handling  limitations,  to 
have  research  assistants  do  the  updating  on  the  file, 
fathering  information  from  various  people  as  needed. 

Part  of  tne  description  for  a  task  involves  the 
specification  at  significant  milestones,  if  possible. 

The  task  leader  has  to  have  some  idea  of  important 
milestones  during  the  progress  of  the  work  and  must 
develop  some  feeling  for  whether  these  milestones  are 
occurring  within  the  resources  expected  to  be  allocated 
to  the  task. 


We  tried  an  on-line  task-planning  chart,  shoeing 

10- week  periods  where  milestones  could  oe  marked  for 
each  task.  Milestones  were  indicated  oy  snowing  an 
NLS  name  for  each  milestone  statement  (see  Fig, 

11- 30).  Therefore,  viewing  this  task-planninj  cnart 
on  a  display,  we  could  "JUHF  TO  NAME",  selecting  one 
of  the  milestone  points  on  the  chart,  anu  a 
description  of  the  milestone  and  its  relationship  to 
the  task  would  then  be  displayed,  A  "JUMP  TO  PETU3N" 
brought  back  the  planning  chart. 

This  shows  some  promise  of  being  useful  in  the 
future,  but  some  refinements  in  display  techniques 
and  milestone  selection  are  necessary  before  it  can 
become  operational. 


Another  use  of  the  content  analyze- 
entries  made  "since  or  before"  a  c 
entries  made  by  certain  people, 
see  who  has  been  updating  the  fiU 
they  have  done  to  it. 


is  to  search  for 
'air,  date,  or  for 
nakes  it  easy  to 
i..tly,  and  what 
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FIGURE  11-30  TASK  MILESTONE  CHART  FROM 
FILE  UPLAN 
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FIGURE  11-31  TOP-LEVEL  VIEW  OF  FILE  UMEET, 

SHOWING  ACCUMULATION  OF  NOTES 
FROM  A  SERIES  OF  MEETINGS  !N  A 
SINGLE  FILE 
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This  la  of  less  lmDortance  for  a  person  vno  is 
updating  nis  o'  n  file,  for  he  prcbaDiy  remembers 
tne  kinds  of  things  he  has  c'r  ?ed.  when  many 
people  work  on  me  sane  file,  it  is  helpful  to  «now 
who  h%s  been  changing  it  and  in  what  areas  they 
have  been  working. 

File  UMEET 

’-e  created  a  separate  file  called  UMEET  for  Plans  and 
notes  from  the  TODAS  activity  meetings. 

This  file  is  sinilar  to  the  uplan  file  in  forr.it. 
On-line  note-taking  by  a  research  assistant,  as 
practiced  in  the  user  system  and  software  Groups,  has 
proven  quite  uat  *ul  for  recording  important  carts  of 
discussions  during  meetings.  The  on-line  note  taker 
has  not  peer  a  distracting  influence  in  nettings;  in 
fact,  she  has  eontrlouted  at  times.  She  is  available 
for  finding  information  in  the  file  and  for  recording 
special  ide&3  in  other  files  upon  request  during  the 
meetings . 

Meetings  are  conducted  with  nard-copy  agenda 
clistnouteu  before  each  meeting.  The  on-line 
notetaxer  has  an  on-line  version  of  the  same  agenda  m 
front  of  her,  as  the  discussion  proceeds,  she  makes 
her  no**3  right  in  the  on-line  agenda. 

Items  left  for  discussion  in  following  meetings,  or 
as  special  Questions  to  oe  resolved  before  the  next 
meeting,  can  be  narked  by  the  ncte-taker  ar.d 
retrieved  from  the  file  for  later  study. 

when  the  meeting  is  completed,  tne  notes  are  condensed 
to  a  meaningful  summary,  distributed  to  the 
participants,  and  displayed  on  a  bulletin  board,  in 
other  words,  the  agenda  for  a  particular  meeting  is 
developed,  during  tne  meeting,  into  minutes  of  the 
meeting.  A  copy  of  the  unaltered  agenda  is  also  kept. 

Successive  meeting  agenda  and  minutes  are  ■•eot  in  one 
file  (see  Fig,  12-31).  This  permits  us  to  search  fer 
discussions  of  various  topics  and  to  receive  answers 
in  chronological  croer. 
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b.  organization  Studies 

Our  organizational  studies  nave  centered  cn  iwo  topics.  The  first 
of  these  is  the  stuay  of  the  "On-Line  Comma  1 1 v --  our  ovr  akC 
group  seen  as  a  unique  example  of  a  small,  close  community  of 
workers  who  make  intensive  use  of  on-line  computer  aids  ir.  tr.eir 
daily  work. 

The  second  area  of  concentration  has  oeen  the  implement* tier  cf 
two  experiments  or.  organization  structure  and  planning  methods  in 
such  a  community. 

1.  On-Line  community 

our  study  of  the  On-Line  Community  is  oesc/ioed  here  ir  t*ms 
of  the  total  working  environment  of  tne  group  am  tie 
structuring  cf  staff  roles  witnin  tne  group, 

a.  Environment 

We  consider  the  total  working  environment,  for  purposes  of 
tms  study,  to  consis  „  of  the  physical  environment  and  tne 
"user  environment."  Tne  matter  is  a  general  term  intended 
to  indicate  the  existence,  availability,  and  performance  cf 
the  numerous  on-line  aids  used  oy  tne  group. 

Physical  environment 

We  have  changed  tne  basic  work  room  or  lacorat ory 
configuration  fro-  isolated  cne-nsr.  offices  and  a  remote 
shop  and  computer/ work  r^-on  to  cr,e«-an  offices  opening 
directly  onto  an  open,  courtyara-li/.e  wo r*  area,  we  still 
use  a  renote  shop  and  computer  room  due  to  ouildir.g 
layout  restrictions .  Tr.e  consoles  were  moved  out  of  the 
offices  into  this  central  working  area,  we  have  cut  in 
separate  lighting  circuits  io  we  can  turn  off  lights  in 
different  parts  cf  the  room,  reducing  reflections  on  tne 
displays,  within  the  work  area,  the  consoles  car.  easily 
oe  regrouped  to  permit  users  to  work  cooperatively. 

On*  effect  of  this  was  to  change  the  personal 
interaction  pattern  dramatically,  simply  oy  increasing 
the  amount  of  interaction. 

A  second  effect  v-»s  to  permit  much  mere  effective 
utilization  of  he  display  facility;  tne  facility  is 
much  more  ’'available"  than  it  otnerwis*  wouin  ha v? 
bee* 
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within  the  general  work  area,  the  console*  (wr.icn  ire 
of  several  different  design*  offering  different 
advantages)  are  set  up  in  varying  configurations,  with 
differing  arrangement*  for  lignting,  s-  sing, 
proximity  to  other  consoles,  etc.  In  general,  tne 
individual  configurations  can  Pe  quickly  and  flexioly 
altered  as  various  needs  arise,  a*  a  result,  an 
Individua  who  is  aoout  to  start  a  working  session  at 
a  console  has  a  considerable  cnoice  cf  ate 

conditions,  figure  11-32  shows  four  view*  of  consoles 
in  the  work  area,  in  actual  use  for  various  modes  of 
work. 

A  further  modification  to  the  physical  environment  wu 
the  addition  of  light  movable  partitions,  for  visual 
privacy.  Tnese  are  low  enough  so  that  a  person,  when 
sitting,  does  not  see  other  people  working  out  can,  by 
standing  or  moving  his  chair  two  or  three  feet,  contact  a 
or  5  other  people  working  at  consoles.  Most  people 
apparently  prefer  to  partition  off  only  the  front  cf 
their  work  stations,  partitions  are  rarely  moved  into 
positions  completely  surrounding  the  work  stations,  when 
seclusion  is  wanted,  people  tend  to  work  in  the  Herman 
Miller  experimental  office,  which  is  isolated  from  the 
general  work  area  by  high  partitions. 

The  Herman  Miller  office  has  also  become  the  place 
where  ^e  system  is  demonstrated  to  visitors. 

Visit  have  the  feeling  that  they  are  inside  the 
working  environment,  and  no  one  else  is  pothered  by 
the  visiters'  presence. 

we  have  adopted  the  practice  of  holding  some  types  cf 
meetings  in  the  Herman  Miller  area  around  one  or  two 
displays,  with  a  research  assistant  taxing  on-line  notes, 

we  have  found  that  display  viewing  is  difficult,  and 
multiple-participant  access  to  the  svsten  ineffective, 
with  meetings  oi  more  than  three  or  four  people. 

on  the  basis  of  our  expediences  with  such  meetings,  we 
are  now  redesigning  the  conference  facility  (see  S^c, 
11-02-0  . 


we  have  found  that  it  is  Highly  desirable  to 
the  system  betn  night  and  day.  Night  access 
area  is  inconvenienced  -0  some  extent  by  the 
security  measures,  particularly  when  we  wisn 


make  use  of 
to  our  work 
existing 
to  work  with 
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FIGURE  11-32  VIEWS  OF  CONSOLES  IN  USE  IN  THE  ARC  WORK  AREA 
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non-SRI  pereonr.el,  sue h  as  consultants.  a  much  nore  open 
and  accessible  working  environment  would  be  greatly 
preferred. 

We  see  great  practical  utility  in  naving  a  maximally 
flexible  physical  environment,  Each  tine  we  have 
increased  the  flexibility  of  the  environment,  work 
interaction  has  increased  without  any  damaging 
increase  in  social  interaction. 


User  Environment 


During  these  two  years  we  have  provided  a  useful,  tr.cugn 
still  evolving,  on-line  text  editing  ana  file 
manipulation  system,  NLS.  This  system  provides  new  tocls 
for  personal  and  group  use.  Appendix  a  describes  NI.S  in 
considerable  detail  from  a  user's  point  of  view. 

Appendix  D  is  a  technical  description  of  r<LS. 

We  have  also  developed  the  Typewnter»oriented 
Documentation-Aid  system,  TODA^  (see  Appendix  a).  This 
provides  sone  of  the  sane  features  as  NI.S  out  can  be  usea 
remotely  by  people  not  physical!;-  in  the  facility.  TODAS 
will  produce  consideraDly  less  load  on  the  timesharing 
system  than  NLS.  *e  nave  experimented  with  remote  use  of 
TODAS  using  portable  typewriter  terminals  with  acoustic 
couplers.  The  resulting  mobility,  with  direct  access  to 
all  of  our  files,  shows  interesting  ooesiuilities  for 
team  collaporation ,  together  or  physically  remote. 

with  the  introduction  of  TODAS,  we  have  provided  more 
opportunity  for  people  to  interact  vita  the  ARC  files 
from  their  offices,  although  some  of  the  processes  are 
slower.  There  has  not  yet  been  widespread  use  of 
TODAS,  hut  this  win  change  with  improvement  in 
service  capacity  of  the  system  and  addition  of  new 
feature*  to  TODAS .  Availability  of  several 
30-character/aecond  typewriter  terminals  will  also 
greatly  increase  the  value  of  TODAS. 

b.  Staff  Functions  and  Activities  within  AFC 

Activities  we  have  identified  as  basic  include  the 
following  ? 


(1)  Hardware 


[2) 


iiO 


Software 
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(3)  Management  bystem  kesearcr. 

(ii)  User  System  kesearcu 

(5)  appa  Network  Participation 

(6)  Operational  tanagement  of  Akc. 

Staff  functions  for  cscn  activity  involve  tne 
specification,  design,  implement* Lion,  documentation, 
evaluation,  and  maintenance  process  as  new  syster. 
features  are  adaea, 

as  we  hire  hardware  and  software  oeorle,  researcr. 
assistants,  and  secretaries,  our  policy  has  oeen  that  a 
person's  capaDilities  must  eo  ceycnd  any  narrow 
specialization.  A  highly  skilled  systems  programmer  must 
have  additional  background  before  he  cp:i  ce  used  eliectivej.y 
in  this  kjroup. 

We  need  people  wno  are  capaole  cf  potn  long-  anc  sr.crt- 
rtnge  planning ,  participating  in  goal  and  sue  goal  setting, 
and  contributing  to  tne  tne  uerigr.,  implementation ,  ar.d 
other  processes. 

For  nost  aku  work  it  is  important  that  people  be  primarily 
oriented  toward  designing  ana  building  tasks  and  less  toward 
contemplative  and  reflective  ones,  However,  since  cur  wotk 
mixes  both  researen  and  development  ncaes  we  must  ce 
capable  of  acting  in  either  capacity  at  different  stages  in 
the  implementation  of  any  given  tasc.  it  is  also  x 
requirement  that  neocle  have  the  ability  to  focus  or. 
different  levels  of  the  endeavor,  alternating  noaes 
frequently  a?  the  needs  arise. 

2.  Experiments  or.  Internal  Activity  Structure 

We  conducted  two  experiments  on  the  use  of  augmented  methods 
for  planning  work.  These  experiments  were  conducted  with  a 
newly  established  group,  the  TClaS  devc-lorment  group,  and  with 
&  well-established,  fairlv  tigat-knit  *reun,  tne  software 
group. 
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a,  TODAS  Development  Activity  Planning 

A  pare  of  ARC  user  system  research  involves  tne 
specification,  design,  implementation,  teaching,  use,  and 
evaluation  of  new  feature/?  being  added  to  TODAS  as  related 
to  anticipated  ARC  and  ARPA  Network  needs* 

The  TODAS  planning  experiment  was  initiated  along  these 
lines  j 

We  first  developed  a  strategy  for  use  as  the  grouD  formed 
and  for  encouraging  it  to  make  further  plans  directed 
toward  ARC  and  TODAS-reiated  goals.  The  stecs  considered 
necessarv  for  the  group  were: 

(1)  Identify  both  internally  and  externally  generated 
goals 

(2)  Agree  on  structure  and  mode  of  operation  of  the 
TODAS  group,  with  tne  following  features: 

(a)  A  group  represer.tive  reporting  to  tne  ARC 
Manager  and  to  external  activities 

(р)  A  team  approach  to  t-a cks  and  planning,  with 
one  leader  for  each  task 

(с)  investigation  of  decision  techniques, 

(3'  Plan  tasks  for  the  group  ana  for  the  indivlual* 
in  the  group  {including  tasks  already  in  progress, 
where  applicable),  we  were  to  do  this  according  to 
the  following  outline: 

(a)  Build  an  easily  visiole  collection  of  task 
alternatives,  to  oe  modified  as  appropriate  after 
analysis  and  review, 

(o)  identify  and  use  the  skills  in  the  sreup, 
securing  other  needed  skills  if  not  available  in 
the  group, 

(c)  Estimate  participants'  level  of  effort  and  the 
timing  involved,  assessing  the  net  effect  of  the 
combined  Plans, 

U)  meet  periodically  to  review  progress,  usually 
every  two  weeks. 
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Meetings  were  intended  to  be  coen  to  interested 
staff  of  ANC ,  with  use  of  an  arreed  upon  forr.it. 

Special  discussion  meetings  (and  otner  .forms  of 
communication)  for  "r.elp"  wr.en  special  procle- 
aituations  arose  were  also  anticipated. 

(5)  Maintain  a  TODAS  "  ir.f  orna  tion  center"  on-line  an 
off-line.  The  basic  files  were  the  following; 

(a)  Kile  KD:  File  Directory  for  TODAS-cnr;r. ten 
links,  This  file  uso  contains  linxs  to  TODAS 
group  participants'  personal  file  directories  and 
linKS  to  the  following  files: 

(  d  )  File  UKz,EI:  Meeting  plans  and  notes 

(c)  rile  UPLAS:  Task  plans  and  status  notes 

(6)  cornunicate  status  of  TODAS  work  to  tr.e  ARC 
Manager  and  tne  ARC  staff, 

Kavin?  deternincu  ^his  strategy,  appropriate  initial 
participants  were  contacted  ar.d  tne  zroup  was 
established . 

The  grout  started  having  meetings  and  developed  a  nc-tir.e 
strategy  that  contained  tne  following  elements; 

il)  a  "facilitator , "  wnose  role  includes  tne  loilewirr: 

(a)  preparation  of  tne  meeting  plan,  with  inputs  fro 
the  rest  of  the  group 

(o'  Guidance  during  tne  meeting  to  ensure  that  all 
important  items  are  discussed 

<c)  providing  an  orderly  way  for  new  or  unexpected 
items  to  oe  discussed  as  appropriate,  or  deferred. 

This  role  was  rotated  among  the  renoersnio  tne 
group  from  meeting  to  meeting,  dec-r.dinp  or.  t-e 
expected  agenda  subject*, 

(2)  A  "process  watcher,"  wncse  role  involves  attention 
to  processes  in  operation  during  the  meeting.  inis 
includes  verbal  and  nor.  -*bai  interactions  oetveer. 
people,  decision  procet  etc. 
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This  was  done  to  give  the  participants  added  insight 
about  less  obvious  features  of  the  meeting. 

This  role  was  rotated  among  the  membership  of  the 
group  from  meeting  to  meeting,  depending  on  the 
oxnected  agenda  subjects. 

(3)  An  on-line  note  taker,  whose  role  includes  the 
following : 

(a)  Distribution  of  the  meeting  plan  and  preparation 
of  the  meeting  notes  outline  before  the  meeting 

(b)  Careful  recording  of  important  discussions  and 
points  made  during  the  meeting 

(c)  retrieval  of  needed  information  from  on-line 
files  during  the  meeting 

(d)  summarising  the  meeting  notes  and  distributing 
them  after  the  meeting 

The  role  of  the  on-line  note-taker  was  filled  by  two 
research  assistants  on  an  alternating  basi«j.  This 
provided  flexibility  and  ensured  that  an  experienced 
note-taker  was  available  for  each  meeting. 

Information  gained  at  th»se  meeting  vac  valuable  to 
the  note-takers  in  tneir  other  day-to-day  work, 

(U)  Regular  participants 

(5*  invited  specialists 

(6)  A  meeting  plan  and  agenda 

(7)  Relevant  documents  produced  on-line  by  any  member 

Distribution  of  documents  was  arranged  before  each 
meeting.  Documents  included  descriptions  of  design 
changes  in  T0DA5,  drafts  of  teaching  documentc,  etc. 

16)  Tentative  plan  for  the  following  meeting 

(9)  An  evaluation  of  the  utility  of  the  meeting. 
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Notes  from  meetings  were  Kept  on  an  evolutionary  basis  go 
separate  oranches  in  one  file,  UMEET,  and  also  in  Pari 
copy  for  distribution  to  ail  members  and  to  a  bulletin 
board. 

Planning 

We  made  an  easily  accessible  lasting  of  tasxs  in  progress 
and  under  consideration,  in  a  seoarate  file  called  UPLAN 
(descrioed  above  in  Sec.  Ii-A-3-c),  w-iicn  can  ce  modified 
by  individual  tasx  leaders  or  cv  research  a,ssistantsa 

This  file  nelpec  increase  tne  extent  to  wnicn  meetings 
were  used  to  evaluate  and  redesign  tasxs,  instead  of 
to  report  information  tr.at  would  not  be  changed  cy 
group  interaction. 

It  facilitated  tne  exchange  of  reportorial 
information  outsiae  tne  meetings,  when  individuals 
could  give  their  full  attention  to  the  file. 

It  was  also  available  during  meetings  for 
reference  or  modification. 

Another  use  of  tne  file  was  to  communicate  infer: ation 
to  people  not  directly  involved  in  the  act  vity,  i.e., 
the  ARC  Manager  and  otners  m  AHC , 

Most  of  the  planning  dealt  with  scheduling  ana  patterns 
for  necessary  interaction  between  tasxs  and  tasx  leaders. 

l:ne  short-tern  goals  appeared  firm  enough  tnat  we  cnose 
not  to  divert  our  resources  to  longer-term  goals  while 
this  activity  was  starting. 

interaction 

Since  this  group  included  people  who  were  involved  with 
other  ARC  activities  such  as  software,  the  Networx 
Information  Center,  and  Management  Science  Research 
(MSR»,  it  explored  seme  interaction  between  activities. 

It  also  provided  an  opportunity  for  the  activity  members 
to  be  involved  in  a  smaller  group  than  tne  ARC  as  a 
whole.  This  changed  tne  group  dynamics  considerabj v. 

The  process  of  identifying  internally  generated  goals 
stimulated  exploration  of  personal  needs  of  the  members 
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cf  the  iroup  to  increase  solidarity,  mutual  liking, 
understanding,  respect,  and  the  desire  to  cooperate. 

Although  social  interaction  initiated  at  early 
meetings  was  beneficial  in  developing  a  cohesive 
working  group,  progress  evaluation  at  various  tines 
indicated  that  it  could  then  be  more  effectively 
continued  outside  of  group  meetings  to  allow  mere 
focus  on  the  primary  group  tasks  related  to  TODAS. 

b.  Software  Activity  Planning 

The  software  activity  is  directed  toward  the  design  and 
implementation  of,  new  system  software  features. 

Strategy 

This  was  tne  second  experiment,  following  the  initial 
results  of  the  TODAS  experiment  described  above.  In  the 
two  years  of  the  contract,  the  software  group  has 
progressively  become  rcoi e  integrated  into  the  total  ARC 
functioning  and  has  doubled  in  size,  one  result  is  that 
more  tasks  that  depend  upon  each  other  are  being 
performed  concurrently.  The  need  for  each  member  cf  the 
software  group  to  oe  aware  of  the  progress  and  design 
modifications  of  the  tasks  undertaken  by  every  other 
member  ci  the  group  has  increased  significantly  as  the 
size  of  the  group  has  grown. 

preplanning  by  thi  MSR  and  group  management  team  included 
t*ose  features  found  to  be  most  useful  from  the  TODAS 
activity  experiment. 

It  recognized  tne  ex  ice  of  leadership 
responsioilities  alrtw  ,  in  effect,  and  formalised 
them. 

The  same  meetirg  format  was  used  as  for  the  TODAS  group. 
We  found  immwdateiy  that  there  was  more  interest  in  task 
discussion  and  Plan  reformulation  and  less  interest  in 
social  interaction  and  group  process  than  in  the  TODAS 
group,  as  a  result,  changes  made  in  the  planning 
procedure  simplified  the  documentation  tc  include  only 
essential  element**  for  communication  by  the  group 

members.  Ve  also  went  through  the  process  of  listing  ail 
current  and  planned  taeks  in  one  consistent  format  in  a 
file  called  SOFT?,  This  resulted  in  a  preliminary 
listing  of  .'30  critical  and  separate  tasks,  with  truly 
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distributee:  task  leadership. 

Leadership 

Leadership  waa  minimal  at  the  group  level,  and  sufficient 
because  of  nigh  motivation  to  complete  tasks  on  schedule. 
The  strongest  leadership  was  at  the  task  xevel. 

This  experiment  is  still  in  progress,  Longer-ranee  goal 
and  task  planning,  with  setter  integration  with  other  An: 
activity  planning,  are  currently  beir.e  developed. 

c.  summary  Comments  on  planning  Experiments 

Active  community  teamwork,  warm  human  relationships,  and 
fcoo  work  attitudes  ire  neceraary  for  our  organisation  to 
function  effectively,  ue  must  encourage  and  develop 
feelings  of  trust  and  cormon  goal  appreciation  so  tnat  cur 
people  can  >or*  closely  together  over  a  long  period  of  time, 
with  so  much  of  themselves  open  to  view  to  others  and  with 
such  interrelated  ana  challenging  tasks  to  be  undertaken. 

We  fount  that  the  TODAS  group  benefited  from  the  initial 
energy  scent  on  interpersonal  relationships,  although  there 
vi*  eventual!/  more  effort  applied  to  the«e  factors  than  we 
found  useful  for  task  accomplishment .  a  careful  balance 
between  application  of  social  and  work-oriented  energy  is  a 
necessity. 

Although  the  TOGAS  experiment  was  r.ot  successful  in  all 
respects,  it  was  ah  experiment  where  the  particular  people 
involved  stand  a  better  cnance  of  succeeding  in  a  future 
experiment  with  a  reoriented  group. 

Software  meetings  were  judged  by  participants  and  outside 
observers  as  extremely  efficient  and  effective  in  meeting 
predetermined  goals.  while  little  attention  was  paid  to 
interpersonal  variables,  group  morale  was  strengthened  bv 
the  meeting  procedure.  Uncertainties  in  task  definition  ar.d 
individual  responsibilities  were  clarified.  The  feedback 
was  reporter  to  be  useful  rather  than  either  flattering  or 
critical*  This,  again,  was  a  cnance  toi  the  participants  to 
be  involved  in  a  smaller  group  than  arc.  This  contributed 
to  the  hi&her  -‘ora..e. 

We  feel  that  L«ie  techniques  developed  ior  recti r.g  and  tao* 
planning  and  for  on-line  .note-taking  will  oe  useful  as  they 
evolve  in  future  activity  planning.  *e  need  to  learn  more 
about  realizing  the  potential  of  improved  interpersonal 
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relationship*  in  ARC,  while  expending  only  a  reasonable 
amount  of  effort  in  doing  so. 

3.  Observations  From  study  of  On-Line  community 

a.  use  of  Public  Files 

The  use  of  public  files  containing  the  work  of  many 
individual  people  seems  to  be  well  accepted  by  the  group. 

Far  more  communication  potential  exists  in  this  environmen 
than  has  yet  been  realized,  although  some  people  have 
started  in  some  interesting  way*. 

our  need  for  development  of  a  Dialogue  support  system  is 
clear. 

Work  habitc  of  the  on-line  community  staff  alto  need 
development  so  that  they  can  use  the  pr**er  of  existing 
features  and  information  in  the  system. 

How  is  the  time  for  further  work  on  methodology  and 
procedures  for  use  of  the  system,  with  the  continued 
parallel  ^volution  of  tne  -ystem  itself. 

b.  System  Dependence  by  the  Group 

As  we  a^r^ent;  we  fin^  that  it  seem*  less  desirable  to  use 
conventional  tools  for  many  tasks. 

This  is  a  problem  to  be  rcsrlved  for  good  use  of  resource* 
and  for  the  purpose  of  not  overlooking  appropriate 
conventional  tool*  where  they  can  still  be  very  effective. 

The  various  ways  that  information  now  get*  into  the  system 

arei 

(1)  Directj 

(a)  on-line  HIS  or  TODAS  use  by  originator* 

Entry  of  new  material 

Duplication  and/or  modification  of  existing 
information 

(b)  on-line  NlS  or  TQDA3  note-taking 
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(2)  Indirect* 

(a)  Transcription  sources! 

Handwritten 

External  documents 
Stenographic  dictation 
Recordings 

individual  use  of  dictating  equipment 
Tape  recordings  of  group  meetings 

(b)  Transcription  processes! 

Direct  NLS  use 

Direct  TODAS  use 
Paper  tape 

we  are  working  toward  a  better  assessment  of  which  tools 
are  most  appropriate  for  the  various  tasks  to  pe  performed 
in  ARC. 

c,  Miscellaneous  Observations 

This  is  a  work-oriented  group.  Most  people  wor*  long  hours, 
usually  at  an  intense  rate;  little  time  is  spent  not 
actually  working. 

There  are  many  more  work  opportunities  for  the  group  and  for 
most  individuals  than  there  are  resources  --  in  terns  of 
both  time  and  funds. 

Group  and  personal  work  management  involve*  many 
difficult  choices  of  tasks  to  be  performed,  postponed,  or 
dropped. 

The  group  frequently  sets  goals  at  higner  levels  than  ft  is 
likely  to  attain. 

This  is  partly  oecause  we  want  tne  new  features  that  will 
nake  the  system  more  powerful;  we  are  users  of  our  own 
result*. 
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Sometimes,  Also,  we  overassess  the  potential  power  of  the 
jystem,  forgetting  that  it  still  has  imitations, 
particularly  in  the  area  of  consistently  good  service 
levels.  This  problem  is  getting  a  great  deal  of 
attention,  however* 

The  interrelatedness  of  tne  on-line  community  tasks  maKes 
planning  very  difficult,  out  obviously  more  necessary, 

C,  Team  Augmentation  and  Dialogue  support 

Cur  efforts  in  management  research  have  oeen  centered  on  the 
attempt  to  developing  a  msff  closely  inteerated,  participatory  way 
of  organizing  people,  effort,  and  *esourcea  toward  specific  goals 
than  is  provided  by  classical  management  theory. 

Toward  this  goal,  we  are  currently  focusing  our  attention  on  the 
problem  of  improving  the  management  of  a  working 
system-development  team,  using  our  own  organization  as  the  subject 
of  experimentation.  This  involves  two  facets  of  augmentation  -• 
namely,  individual  augmentation  and  team  augmentation, 

individual  augmentation  is  simply  our  continuing  effort  to 
provide  ways  of  improving  the  working  capability  of  individual 
members  of  a  team. 

Id am  augmentation  involves  the  developnent  of  improved  means 
for  coordinating  the  efforts  of  individuals  and  for  integrating 
their  individual  contributions  into  coherent  team  action, 

1,  Recent  Efforts 

A  portion  of  our  recent  MSR  effort  has  been  invested  in 
formulating  a  "team-augmentation"  approach.  The  initial 
emphasis  is  strongly  oriented  toward  the  means  for 
communicating  and  collaborating  effectively  on  issues  embedded 
within  a  complex  and  evolving  problem  domain. 

An  important  facet  of  this  approach  has  been  a  preliminary 
study  for  a  "Dialogue  support  system"  (D3S)  ••  a  special  system 
of  coordinated  features  which  could  support  the  communication 
and  integration  of  collaborative  dialogue  among  team  members. 

Appendix  B  is  a  more  detailed  discussion  of  this 
formulation,  as  extracted  from  the  PhD  thesis  of  David  A. 
Evans  (see  Ref,  1) , 
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2.  Future  Approaches  to  Team  Augmentation 

Experimentation  with  roles,  record-keecing  conventions, 
collaboration  procedures,  decision-making  practices, 
documentation,  etc,  will  be  a  rich  domain  for  exploratory  MSP 
work. 

The  following  discussion  of  fast  editing  and  puolication, 
"super-documents, "  and  augncnttd  conferencing  gives  a  view  of 
features  needed  for  tear.  augmentation. 

c.  Fast  Editing  and  Publication 

Our  already  fast  editing  techniques  will  continue  to  evolve, 
and  we  plan  to  concentrate  early  upon  -utomttic  production, 
from  our  on-line  files,  of  hard  copy  riving  a  very  flexible 
composition  of  text,  diagrams,  tables,  equations,  footnotes, 
and  Indicesc 

The  design  of  hard-copy  formatting  conventions  must  be 
related  directly  to  the  way  in  whicn  the  associated  file 
material  can  be  studied  and  manipulated  on-line, 

b.  "Super-Documents" 

We  have  been  doing  researcn  leading  to  the  development  and 
production  of  very  large,  very  complex  documents  containing 
numerous  sections  whose  details  are  highly  interdeoendent . 
These  documents  will  be  subject  to  frequent  updating.  This 
will  involve  further  work  on  techniques  for  creating  and 
using  special  indices,  footnotes,  reader-suppor vive 
comments,  cross-references,  etc. 

We  currently  have  quite  powerful  techniques  for  aiding  an 
individual  or  a  small  report-writing  team  to  produce 
documents  of  the  usual  research-report  size  and  complexity. 
Part  of  our  approach  to  team  augmentation  will  be  the 
expansion  of  these  techniques  to  allow  for  much  greater 
scope  and  complexity  m  documents  and  much  more  fluid 
interaction  among  the  team  member**  who  create  them, 

A  team  tackling  a  complex  system-ce''eloDment  Drojfct  must 
provide  itself  with  the  nigneet  possible  visibility  over  its 
working  environment  --  i.e.,  ever  the  following  factors: 

Planning:  plans,  contingency  alternatives,  resource 
commit  tents,  status,  criticisms 
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Design*  designs,  design  principles,  constrains, 
estimates ,  Analyses,  supportive  data,  relevant  needs  and 
possibilities 

Operation*  roles,  task  definitions,  assignments, 
policies,  operational  procedures  and  conventions. 

we  intend  to  develop  ana  Keep  up  to  date  a  lar^e,  detailed, 
highly  cross-referenced  and  well-indexed  “super-document" 
that  contains  Just  such  a  description  of  our  own 
project-team  activity,  our  techniques  for  facilitating  its 
modification  and  republication  will  be  under  constant 
evolutionary  pressure. 

c,  collaborative  Use  of  On-Line  File  Systems 

On-line  access  by  collaborators  to  each  other’s  files,  as 
provided  *y  a  number  of  today's  time-sharing  systems,  leaves 
much  to  be  desired  in  supporting  effective  dialogue. 

An  effective  dialogue-3upport  system  is  essential  to  team 
augmentation*  Hand  in  hand  with  the  "super-document'' 
facility  descrioed  above  must  go  some  ^uch  ability  as  the 
following  t 

Any  team  member  at  a  display  console  can  study  swiftly 
any  portion  of  the  super-document's  structured  files, 
our  current  system  is  fairly  good  for  this  purpose,  but 
not  yet  adequate  for  dialogue  study. 

whenever  he  wishes  --  as  though  he  were  pencil-marking 
his  private  uraft  vitn  marginal  comments,  underlines, 
encircled  passages,  arrows,  etc,  --  he  can  introduce 
"comments*  that  are  freely  sp  inkled  with  explicit 
references  to  any  *pecific  item  (e.g,  any  character, 
word,  graphic  entity,  or  expression)  within  anybody's 
prior  entry.  (Notei  the  term  "comment'1  is  used  here  and 
in  the  following  discussion  in  a  very  broad  sense  --  a 
comment  is  any  entry  which  in  some  way  points  to  a 
previous  entry.) 

This  commenting  capability  must  pe  managed  by  the 
computer  eo  that  it  does  not  matter  if  ether  peoDle 
are  simultaneously  scanning  the  same  material  or 
affixing  comments  to  th<;  same  it^rs, 

when  creating  &  comment  entry,  he  needs  f?.exible  aids 
and  methods  for  arranging  interspersed  or  concurrent 
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display  or  the  referenced  passages,  for  designating 
the  explicit  entities  he  wishes  to  reference,  and  for 
suspending  operations  temporarily  while  he  checks 
related  material. 

Conversely,  ne  neeas  a  way  of  seeing  any  cogent s  tnat 
reference  a  passage  ne  is  inspee'irg. 

Categories  night  ne  defined  oy  autnoranlp,  date  of 
creation,  text  content,  or  assirr.*i  membership  in 
predefined  categories. 

He  also  needs  a  great  aea±  of  control  ever  this, 
however;  much  of  tne  tine  ne  win  not  want  to  see 
any  comments,  or  only  comments  falling  into  certain 
categories. 

He  also  needs  considerable  control  over  tne  way  tne 
system  displays  the  comments  that  he  wants  tr  see 
--  in  specified  portions  of  the  screen,  in 
full-text  or  condensed  form,  etc. 

He  neeas  the  anility  to  set  up  "innunciator  call.?"  to 
various  people,  or  sets  of  people,  to  request  their 
special  attention  (at  seme  level  of  rrierity)  to  a  given 
comment. 

All  of  the  interactive -dialogue  entries  immediately 
aecome  part  of  tne  super-document ,  i-posm?  a  potentially 
very  complex  comment  network  ("network"  Because  comments 
can  refer  to  comments  in  indefinite  extension). 

It  will  be  hard  to  keep  track  of  the  relationships 
among  these  comments  and  the  substantive  records  about 
which  the  dialogue  is  oriented. 

Their  relationships  need  never  be  ambiguous,  but 
consider  tne  Drooler,  of  tryina  to  study  such  a 
structure  to  determine  where  we  now  stand  ir.  our 
developments  and  discusalor,  especially  wnen  it  is 
the  record  of  a  complex  syst em-oesigr.  process  and 
the  interactive  dialogue  among  very  active  people. 

This  is  about  the  most  difficult  central  challenge  in 
effectively  augmenting  a  team  --  t  at  of  developing 
computer  aids,  working  methods,  etc.  to  allow  a 
skilled  person  to  be  highly  effective  in  digesting  the 
content  and  implications  of  such  a  record,  and  to 
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develop  a  substantive  next-atage  aeeign  :r  plan  that 
integrate#  the  dialogue  contribute  one . 

Essentially  similar  techniques  are  required  to 
augment  any  individual'#  central  intellectual 
capability  for  synthesising  the  next  stage  of 
development  in  a  plan  or  design.  To  the  extent 
that  ve  are  successful  with  this,  we  should  be  able 
to  offer  strong  guidance  for  capability 
augmentation  ever  wide  ranges  of  individual  and 
team  activities, 

d.  Conference  Augmentation 

There  is  great  potential  value  in  direct  augmentation  of 
conferences  and  meetings.  When  people  are  gathered  together 
to  consider  a  proposal  or  argument,  or  to  coilaoorate 
actively  on  a  problem,  there  are  many  possibilities  for  the 
development  of  techniques  ana  facilities  to  make  their  work 
more  effective. 

There  is  a  wide  range  of  possiole  approaches  to 
conference  augmentation,. 

At  one  extreme,  each  participant  would  be  an 
experienced  NLS  user  ar.d  would  have  his  own  console; 
sophisticated  facilities  would  be  provided  for 
'•linking”  the  consoles  in  various  ways  to  augment 
communication. 

At  the  other  extreme,  there  would  be  only  a  single 
console  with  a  special  operator;  special  techniques 
for  integrating  the  NLS  facility,  the  operator,  and 
the  conference  participants  into  a  working  system 
would  be  needed. 

Between  these  two  extremes,  a  variety  of  intermediate 
approaches  is  possiDle, 

For  any  of  these  approaches,  a  central  problem  is  the 
development  of  conference  procedures  and  the  organization 
of  on-line  information;  both  procedures  and  information 
structures  must  be  developed  in  such  a  way  as  to  gain  t;»e 
greatest  possible  advantage  from  the  computer  facility. 

This  development  of  conference  procedures  and 
information  structures  should  be  done  experimentally, 
under  actual  usage  conditions. 
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We  have  already  experimented  with  augmenting  meetings 
by  having  one  peruon  operate  nls  as  an  on-line 
note-taker,  where  all  participant*  can  see  tne  display 
(see  Sec,  XI-A-J-b) , 

On  the  basis  c f  recent  experience,  we  plan  to  provide  petter 
facilities  for  groups  of  people  working  together  at  console* 
and  for  small  meetings  where  consoles  are  net  available  for 
everyone  (or  where  not  all  participants  are  nls  users). 

This  will  permit  experimentation  with  intermediate 
approaches  lying  between  the  two  extremes  escribed  above. 

The  facility  will  consist  of  a  meeting  room  equipped  with 
projection  TV,  several  appropriately  designed  consoles, 
and  furniture  designed  so  tha*  three  or  four  people  may 
work  at  the  consoles  with  ten  o  so  less  active 
participants. 
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A,  Introduction 

This  section  reviews  the  current  status  of  the  ARC  computer 
facility  and  describes  the  hardwire  development  that  has  been  done 
during  the  course  of  this  contract. 

The  first  part  oriefly  describes  the  computer  facility, 
including  both  the  computer  as  leased  from  XDS  and  the  special 
equipment  that  has  been  added  by  ARC, 

The  second  Part  discusses  modifications  and  improvements  to  tne 
facility  that  have  been  planned  and  are  now  in  progress. 

The  tnlrd  part  presents  some  comments  on  features  of  the  system 
design  and  discusses  some  of  the  reliability  ana  maintenance 
experience.  Because  of  it*  unique  design,  the  display  system 
is  emphasized,  A  summary  of  maintenance  costs  for  the 
display-generator  and  television  portions  of  the  system  is 
included. 

B.  The  Computer  Facility 

The  configuration  of  the  ARC  computer  facility  has  oeen  relatively 
stable  over  the  past  two  years.  There  have  oeen  some  peripheral 
additions,  in  particular  the  ARPA  network  interface  and  an 
external  core  system;  these  are  discussed  below. 

The  current  facility  is  sho’vi  in  Figs.  III-1  and  1 1 1 - 2 . 

1.  The  Leased  Computer 

rigure  IIX-1  is  a  bloek  diagram  of  tne  facility  as  leased  from 
XD3 . 

A  central  processor  with  timesharing  hardware  operates  from  a 
6iiK  memory  in  1  banks  with  24-' it  words  and  a  cycle  tine  of  1.3 
microseconds. 

On  channels  sharing  memory  access  with  the  CPU  are  3  magnetic 
tape  drives,  a  paper-tape  nation,  and  communications  equipment 
for  16  Teletypes, 

A  second  memory  buss  provides  direct  access  to  memory  for  the 
RADs  (Rapid  Access  Devices,  i.e.,  drums)  and  the  non-XDS 
portion  of  the  facility,  designated  “Special  Devices  Channel” 
in  Fig ,  III-l. 

There  are  three  drums  on  the  system,  operating  from  a  conmon 
controller  and  accessing  memory  through  an  XDS  device  called 
a  Direct  Access  commmunications  Charnel  (DACO.  Each  drum 
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has  a  capacity  of  500,000  2U-bit  words,  a  transfer  rate  of 
1« 0,000  woras  per  second,  and  an  average  latency  of  17 
liillisecondSt 

2.  Special  Devices  Channel 

Figure  III-2  ii  a  block  diagram  of  the  portion  of  the  facility 
that  has  been  put  together  by  ARC.  The  following  sections 
describe  the  major  units, 

&«  Executive  Control 

The  executive  control  provides  an  Interface  to  the  5U0 
through  the  Memory  Interface  Connection  (MIC),  It  acta  as  a 
multiplexer  that  allows  asychronous  access  to  core  dv  any  of 
the  6  devices  connected  to  it. 

The  executive  control  decodes  computer  input/output 
instructions  and  passes  them  along  as  signals  to  the 
various  devices.  It  accepts  interrupts  from  the  devices, 
synchronies  them,  and  passes  their,  along  to  the  computer. 

It  accepts  addresses  and  requests  for  memory  access  from  the 
various  devices,  determines  relative  priority  amonf  them, 
and  synchronises  their  access  to  y*C  core. 

The  executive  control  includes  extensive  debugging  and 
monitoring  aids,  it  allows  the  monitorinc  of  data  and 
addresses  for  any  selected  device  and  permits  “off-line” 
operation  of  any  of  the  devices. 

b.  Disc  File  system 

The  disc  file  system  consists  of  &  Bryant  Model  *061  disc 
file  and  associated  controller*  The  system  has  a  capacity 
of  32  million  word*,  a’  average  access  time  of  1P5 
milliseconds,  and  a  data  transfer  rate  of  *3,000  words  per 
second,  A  relatively  simple  field  modification  will  double 
the  present  capacity. 

The  disc  controller  was  designed  and  built  by  Bryant  to 
interface  with  the  executive  control,  SDecifications  for 
the  controller  were  developed  Jointly  by  Bryant,  Projeet 
GENIE  at  UG  Berxelcy,  and  Ski, 

c.  Display  system 

The  display  system  consists  of  two  identical  subsystems. 
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each  with  *  display  controller,  a  display  generator,  and  b 
high-resolution  5-inch  CRT*.  A  closed-circuit  television 
system  carries  display  images  from  tne  CRTs  to  television 
monitors  ir.  the  working  aret.. 

The  display  controllers  were  designed  and  built  at  SRI. 

They  access  and  process  "command  tables"  that  are  resident 
in  940  core, 

A  command  is  roughly  associated  with  a  user  and  points  to 
a  “display  list"  in  tne  user's  core  space.  The  display 
list  in  turn  points  to  buffers  containing  actual  display 
instructions  (commands  to  the  display  generator  to 
produce  images) . 

The  display  controller  handles  all  core  accessing, 
including  memory  mapping  for  tne  user's  core  space.  It 
passes  the  display  instruction*  along  to  the  lisplay 
generator. 

The  display  generator  and  CRTs  were  purchased  from  Tasker 
Instruments  to  3RI*s  specifications.  They  have  general 
character  and  vector  capabilities , 

presentations  for  each  of  tne  6  CRT*  are  generated 
sequentially,  and  unblahk  signals  from  the  display 
controllers  select  one  or  more  of  the  CRTs  at  a  given 
time, 

A  high-resolutior.  (675-line)  closed-circuit  television 
system  transmits  display  pictures  from  each  CRT  to  a 
television  monitor  at  a  corresponding  work-station  console, 
(Figure  11-32  shows  several  work-station  designs.) 

d.  Input  Device  control 

in  addition  to  the  television  monitor,  each  work  station  has 
a  keyboard,  binary  keyset,  and  mouse,  Anpendix  A  describes 
the  use  of  these  devices. 

The  state  of  these  input  devices  is  read  by  the  input  device 
controller  at  a  preset  interval  (about  30  milliseconds)  and 
written  into  a  fixed  table  in  940  core, 

bits  are  added  to  information  from  the  keyboards, 
keysets,  and  mouse  switches  to  indicate  wnen  a  new 
character  has  been  received  or  when  a  switch  has  changed 
state  during  the  sample  period,  a  new  character  or 
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switch  change  causes  an  interrupt  to  oe  issued  at  tne  end 
of  the  sample  period. 

Mouse  coordinates  are  digitized  by  an  A/D  converter  and 
formatted  by  the  input  device  controller  as  bean-Dosition 
instructions  to  the  display  generator,  A  user  program 
may  include  the  mouse  coordinates,  as  written  py  tne 
input  device  controller,  as  part  of  a  display  list.  This 
allows  the  mouse  position  to  be  continually  displayed 
without  ittention  from  tne  CPU, 

e#  Line  Printer 

The  line  printer  it  a  96-character  drum  printer  leased  from 
Data  Products  corporation  (Model  M600-11A).  Wxtn  the  96 
characters,  printing  speed  is  3UO  lines  per  minute. 

The  line  printer  ontroller  processes  print  puffers  o? 
arbitrary  longth  (single  line  puffers  are  normally  used) 
that  have  been  set  up  in  core  by  a  controlling  program. 
Operation  of  the  printer  controller  is  described  in  Appendix 
C. 

X,  HetworK  Interface 

The  network  interface  provides  communication  cetween  tne  9U0 
and  an  Interface  Message  Processor  ( IMP)  on  the  ARPA 
Computer  network.  The  interface  operates  fron  message 
buffers  in  9iC  core.  Messages  to  the  Networx  are  read  py 
the  interface  from  these  puffers  and  transmitted  to  the  imp, 
Similarly,  messages  received  from  the  imp  are  written  into 
buffer  space  in  ?hO  core.  Instructions  from  the  9U0  enable 
the  system  for  receiving  messages  and  control  the  sending  of 
messages,  a  •'linked-ouffer"  scheme  permit*  flexible  memory 
allocation. 

Operation  of  the  network  interface  is  described  in  pore 
detail  in  Appendix  c.  The  interface  message  processor  and 
its  communications  protocol  are  discussed  in  detail  In  Pef. 
2. 

C.  Modifications  in  Progress 

Two  modifications  to  the  facility  chat  will  provide  significant 
improvement  in  service  are  now  being  implemented.  These  are  an 
external  core  system  and  faster  drums,  in  addition,  an  accurate 
clock  system  is  being  added. 
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1.  External  Core  system 

The  external  core  system  has  oeen  completed  and  will  be 
integrated  into  the  facility  in  the  near  future. 

The  primary  purpose  of  this  core  system  ia  to  provide  storage 
for  display  regeneration,  Display  buffers  are  presently  in 
“frozen  page*''  in  9i0  core  -•  a  significant  factor  in  Uniting 
system  responee,  since  thay  take  up  apace  that  could  otherwise 
be  uaed  for  swapping,  (see  Sec.  IV  for  a  discussion  of  factors 
affecting  response.) 

rigure  I I I -3  snows  the  special  devices  channel  as  it  will  be 
reconfigured  when  the  core  system  is  integrated. 

The  inter-core  controller  controls  transfer  of  data  between 
external  core  and  9ko  core.  It  has  two  nodes  of  operation! 

(1)  A  bloc*  transfer  mode  allows  the  transfer  o i  blocws 
of  up  to  20g6  words  between  any  two  locations  lr,  the  two 
cores.  (Note  that  transfer  can  be  between  two  locations 
in  the  same  core. ) 

(2)  A  snort  transfer  mode  allows  the  transfer  of  snort, 
fixed-length  buffers  between  fixed  locations  in  9U0  core 
and  external  core.  This  mode  is  easier  to  set  up  than 
the  bloc*  transfer,  and  requires  fewer  memory  accesses 
for  control,  it  will  be  used  for  such  functions  as 
transferring  single  characters  or  other  control 
information  between  the  two  core  systems. 

The  operation  of  the  inter-core  controller  is  descrioed 
in  more  detail  in  Appendix  c* 

The  external  core  itself  currently  consists  of  a  tingle 
32,000-word  bank  with  access  switching  to  allow  access  by  up 
to  eight  devices.  Provisions  are  included  ir.  the  design  to? 
expansion  to  16  devices  and  two  core  banks  of  6ht0QC  words 
each.  The  core  cycle  time  is  1.5  microseconds  and  the  word 
length  is  2ii  bits. 

The  interface  to  external  core  has  been  designed  so  that 
it  is  identical  to  the  interface  to  9 h.0  core  (through  the 
Executive  Control).  A  device  may  be  simply  plugged  into 
either  core  system. 

As  shown  in  rig.  III-3#  we  will  initially  be  operating  both 
display  systems,  the  network  interface,  and  the  line  printer 
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iron  external  core.  These  are  the  devices  tn&t  need 
constant  buyers  for  relatively  Ion?  periods  and  therefore 
require  frozen  pales  when  ooeratini  from  9kO  core. 

2,  faster  Drums 

from  the  system  response  studies  (see  Sec.  IV)  it.  is  apparent 
that  a  primary  factor  in  response  is  the  swapping  bandwidth. 

To  improve  response  (and  add  more  ubers),  we  are  in  the  process 
of  replacing  the  XDS  drums  with  Univac  FH«k32  drums. 

These  drums  rotate  at  7200  RPM,  living  a  transfer  rate  of 
365,000  words  per  second  (as  compared  to  120,000  for  the 
present  drums)  and  an  average  access  time  of  about  a 
milliseconds. 

in  addition,  ve  are  formatting  the  new  drums  in  a  \i ay  that 
will  allow  a  page  transfer  to  begin  at  any  position  on  the 
drum.  Since  a  20EA-word  page  fills  two-thirds  of  a  band, 
this  will  give  an  average  page  transfer  time  of  about  A 
milliseconds. 

The  interface  for  the  drums  will  te  designed  and  built  by  ARC, 
It  will  connect  to  the  9a0  through  a  second  Memory  Interface 
Connection  (MIC),  replacing  the  current  FAD-DACC  combination 
shown  in  Fig.  III-1. 

3.  Clock  System 

An  accurate  clock  system  is  Deing  added  to  assist  us  in  system 
measurements. 

This  clock"  system  provides  two  types  of  time  information  -- 
absolute  and  relative  -•  that  are  written  into  fixed 
locations  in  9A0  eore  at  resular  intervals. 

Absolute  time  conaists  of  binary  representation*  of  year, 
month,  day,  hour,  minute,  and  second. 

Relative  time  information  consists  of  a  single  2A-bit 
number,  incremented  and  written  into  core  every  ioo 
microseconds. 

The  long-term  drift  cn  the  clock  will  be  less  than  1  second 
in  250  days, 

A  more  complete  description  of  the  clock  system  is  given  in 
Appendix  c. 
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D.  Note**  bn  System  Design  and  Reliability 
1.  Display  System 

The  display  system  in  use  is  somewhat  unusual  in  th  it  uses 
central  display-generating  equipment  and  a  closed-c~  uuit 
television  system  to  distribute  images  to  the  working  area. 

This  approach  to  a  display  system  was  chosen  on  the  basis  of 
cost  and  flexibility,  A  description  of  the  system  and  of 
considerations  that  went  into  its  design  is  given  in  an  earlier 
report  (Ref.  3). 

we  now  have  considerable  experience  in  operating  th is  system 
and  are  still  very  pleased  with  ttu  basic  approach,  but  we  have 
had  some  problems  with  the  component  equipment  involved. 

The  closed-circuit  television  system  offers  several  distinct 
advantages  over  other  means  of  producing  displays  at  a  work 
station. 

The  system  is  extremely  flexible  as  to  the  location  and 
design  of  working  consoles,  since  only  a  television 
monitor  and  a  video  line  are  required  to  present  the 
display  at  each  console.  This  allows  freedom  to 
experiment  with  different  types  of  consoles  (Ref.  k)  and 
to  move  consoles  about  without  cabling  problems, 

The  video  signal  is  inverted  to  provide  a  biack-on-wnite 
display.  This  presentation  is  usable  in  higher  ambient 
light  conditions  than  the  usual  bright*on^dark 
presentation,  and  flicker  in  the  display  imare  (due  to 
low  generation  rates)  is  much  less  noticeable  to  the 
user. 

with  proper  adjustment  of  the  television  camera,  a 
significant  storage  time  can  be  obtained  on  the  vidicon 
surface.  This  greatly  reduces  the  flicker  effect  that  is 
present  in  the  original  CRT  presentation,  with  this 
system  we  find  it  possible  to  regenerate  displays  at 
about  20  cycles  per  second, 

Maintenance  features  are  another  significant  advantage. 

The  display  equipment  at  the  actual  work  station  is  quite 
simple,  consisting  of  only  a  television  monitor  which  can 
be  replaced  by  a  spare  for  maintenance. 

The  display-generating  equipment,  which  requires  more 
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complex  maintenance  and  repairs,  la  located  centrally  in 
the  computer  room.  This  maxes  it  very  easy  to  maintain 
an  uncluttered  office  environment  in  the  working  area. 

jurthermore,  since  there  if  not  a  fixed  one-to-one 
relationship  between  display-generating  equipment  and 
work  station*,  when  a  portion  of  the  display  system  is 
down  for  repairs  the  working  consoler  that  remain 
operative  may  be  freely  selected  on  the  bast:  j t  current 
needs. 

Having  two  identical  display  systems,  from  display 
controller  through  actual  monitors,  has  been  a  major 
factor  in  maintaining  up-time  in  spite  of  the 
unexpectedly  high  level  of  maintenance  required  on  the 
system. 

The  uae  of  video  to  distribute  disday  images  offers  several 

other  possibilities  that  we  nave  not  yet  fully  exploited. 

Tor  the  television  monitor  on  which  t.ne  image  is 
presented,  a  wide  range  of  accessory  equipment  is 
commercially  available.  For  example,  we  nave  used 
high-quality  projection  television  at  the  Fail  Joint 
Coaputer  Conference  in  1968  and  at  the  ASI3  Conference  in 
1969.  It  is  possible  to  use  multiple  TV  noriters  or 
intermediate-size  projection  equipment  for  smaller 
groups.  This  will  be  a  major  factor  in  the 
team-augmentation  work  to  be  carried  out  under  tne  next 
contract.  i 

The  video  capability  offers  additional  flexibility  in  the 
images  that  may  be  used  on  the  screen.  For  example,  in 
the  conferences  mentioned  above,  live  TV  pictures  of  the 
people  and  equipment  involved  were  freely  used,  mixed 
with  t-he  computer-generated  image.  This,  again,  will  be 
a  significant  factor  in  team  collaboration  at  a  distance 
where  pictures  of  the  people  involved  can  oe  used,  either 
mixed  or  inserted  with  the  computer-generated  image. 

Another  use  of  the  video  that  will  become  increasingly 
important  is  the  viewing  of  microfiche  documents.  Many 
systems  are  now  available  and  nore  are  coming  on  the 
market  for  the  storage,  retrieval,  and  viewing  of 
microfiche  on  closed-circuit  television. 
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2.  Maintenance  Experience 

a.  General 

in  general  the  reliability  of  the  facility  has  been  very 
gcod;  the  computer  up-tine  has  been  extremely  high.  The 
reliability  of  the  disc-file  system  has  been  fair,  we  had  a 
period  of  several  months  of  above-normal  error  rate,  and  5 
days  down  while  cIocks  were  rewritten;  however,  the  troubles 
now  seem  to  have  been  corrected, 

one  notable  exception  to  this  has  been  the  line  printer, 

we  originally  bought  a  potter  chain  printer  which 
turned  out  to  have  marginal  print  Quality  and  was  very 
unreliable,  we  had  great  difficulty  in  getting 
maintenance  from  Potter,  and  we  finally  reolaced  tne 
unit  with  a  Data  Products  drum  orinter.  Like  the 
Potter  printer,  this  has  96  printing  characters  with 
upper-  and  lower-case  alphabet.  The  print  quality  is 
excellent  and  so  far  it  has  been  v'  v  reliable. 

b.  Display  system 

We  have  spent  sore  effort  on  maintenance  of  the  display 
system  than  any  other  part  of  the  facility;  since  it  is 
somewhat  unusual,  wc  will  discuss  some  of  the  problems 
encountered  and  summarize  the  maintenance  costs. 

One  of  the  basic  limitations  of  the  system  is  the  lack  of 
enough  total  light  on  the  vidicon  surface.  This  means 
that  many  design  factors  arc  marginal.  The  Tasker  CRTs 
run  at  such  nigh  intensity  that  their  life  is  relatively 
short.  This  high  intensity  also  causes  difficulties  in 
maintaining  good  focus  over  the  entire  image.  To  operate 
with  these  low  light  leve3,s,  the  vidicons  must  be  quite 
sensitive;  since  sensitivity  drops  off  with  age,  they 
have  a  relatively  short  useful  life. 

Because  the  writing  speed  of  the  Tasker  display 
generators  is  1  wer  than  expected,  we  still  have  a 
flicker  problem  when  all  6  screens  on  the  system  in  use 
are  reasonably  full  of  text.  To  some  extent  we  are  able 
to  compensate  for  this  by  careful  adjustment  of  the 
vidicon  beam  current  and  target,  but  this  adjustment 
needs  frequent  attention,  we  have  considered 
longer-persistance  ohoaphora  on  the  TV  monitors  and  will 
experiment  with  this  in  the  near  future. 
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in  addition  to  these  difficulties  there  are  some  oasis 
weaknesses  in  the  design  of  the  Tasker  system  and  the 
television  system* 

(1)  Tasker  system 

Sockets  for  circuit  cards  are  not  of  high  quality. 

This  results  in  contact-resistance  preblems, 
especially  in  the  analog  circuitry. 

Deflection  circuitry,  with  its  nany  adjustments,  is  ao 
hard  to  get  at  that  it  is  left  in  a  partially 
assembled  state. 

Logic  circuits  still  do  not  have  all  pull-up  problems 
corrected,  resulting  in  a  narrow  range  on  the  clock. 

The  active  deflection-sensing  circuit  requires 
frequent  adjustment. 

The  focus  vs,  beam  position  circuits  perform  very 
poorly. 

(2)  Television  System 

The  preamplifier  tubes  on  tne  television  cameras  tend 
to  be  very  noisy.  These  tubes  must  initially  be 
selected  for  low  noise  to  get  really  good  pictures, 
and  their  life  ie  very  short. 

We  are  currently  in  the  process  of  replacing  all  of 
the  preamplifier  circuit  boards  wi  n  a  new 
solid»stat e  circuit  now  delivered  in  new  Qt  cameras 
of  this  type.  This  circuit  uses  an  fET 
preamplifier  with  very  low  noise  and  hopefully  no 
problems  in  reliability. 

Controller  power  supplies  are  poorly  designed  and 
require  toe  frequent  replacement  of  parts, 

c.  Maintenance  Costs 

The  following  is  a  summary  of  the  costs  for  maintenance  of 
the  display  and  television  systems  for  the  past  y:?ar.  Both 
include  the  frequent  "tuning '  neceasery  to  maintain  good 
picture  quality.  These  are  the  costs  for  maintaining  o 
operating  work  stations,  but  iorae  effort  has  been  spent  on 
the  ecuinmert  not  in  regular  use,  ve  expect  this  to  ro  up 
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about  50  percent  when  12  stations  are  In  operation. 


TV  System 

labor  25,665 

Vidicons  3,365 

Picture  Tube*  S95 

Preamp  Tube#  1,200 

All  other  part*  1 , 0U0 

Total 

Tasker  System 

labor  7,905 

CRT  *  *  3,000 

Miscellaneous  200 

Total 


32,165 


11,105 


Hotet  Tne  Tasker  system  is  maintained  at  a 
"KceD«lt-going-well-enougn-ao«peopie-can-vorKH  level,  and 
it  lives  with  many  weaknesses. 


3.  Hardware  Design  and  Construction  Techniaues 


a,  logic  Design  Aid* 


TKe  wirelist  generator  program  described  in  an  earlier 
report  (Ref,  3)  is  atxll  oeing  used.  The  input  format, 
iagnostic  aids,  and  general  fora  of  the  program  are 
essentially  the  same  as  in  the  p-st,  in  the  past  the 
wirelist  output  was  used  to  produce  documentation  that  aided 
a  technician  in  hand  wiring j  now  it  produces  a  punched  tape 
that  in  turn  controls  a  semiautomatic  wire-wrapping  machine. 
This  wire-wrapping  service  is  obtained  from  a  local  supplier 
and  results  in  more  accurate  wiring,  lower  wiring  cost,  ana 
faster  turnaround  in  going  from  logic  equations  to  finished 
wiring. 


Regarding  accuracy,  no  misplaced  wires  have  been  found  to 
date,  although  a  very  minor  number  of  broken  vires  and 
vires  snorted  to  pins  have  been  observed. 


The  wiring  itself  costs  about  23  cents  per  wire.  Also, 
above  the  cost  of  running  the  basic  wirelist  generator 
program,  there  is  an  additional  cost  of  20  cents  per  wire 
for  preparinc  the  paper  tape  used  to  control  the 
wi^e-wrapping  "aching. 


Turnaround  tine  for  wire-wrapping  la  short,  tywictlly 
less  than  a  week  for  a  design  containing  100 
integrated  circuits,  of  course,  this  is  subject  to 
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considerable  variation,  depending  on  the  vorK  lead  of 
the  company  performing  the  vire-vnppin* . 

Meet  o t  the  general  comments  in  the  orevious  report 
concernim  the  utility  of  the  vireliet  generator  . rogran 
etill  hold. 

However,  experience  has  ahown  the  desirability  of 
maintaining  a  fairly  complete  aet  of  logical 
schematics*  complete  with  circuit  locations  and  pin 
numbers,  in  addition  to  the  designer's  sketches  and 
listings  provided  by  the  wireliat  generator. 

The  previoua  report  on  this  contract  (Ref.  3) 
implied  that  the  akctchea  and  Hating  were 
aufficient  for  equipment  maintenance  and 
troubleshooting.  This  is  true  as  long  as  the 
original  designer  performs  the  maintenance,  with 
the  inevitable  turnover  of  personnel  that  takes 
place  on  a  long-term  project,  someone  other  than 
the  designer  eventually  become*  responsible  for 
keeping  a  given  device  operating.  Under  this 
circumstance,  a  schematic  is  an  invaluable  aid. 

b.  Construction  Techniques 

The  construction  techniques  of  the  most  recent  units  can  be 
seen  in  rig,  IH-k.  The  hardware  implementation  consists  of 
an  array  of  sockets  that  will  directly  accept  a  dual  inline 
pacv:~ff«d  integrated  circuit  (commonly  called  a  "DIP" ).  The 
arrays  of  DIPS  are  mounted  perpendicular  to  the  horizontal 
plane  on  the  front  of  the  rack  in  which  they  are  mounted. 

The  circuit  arrays  can  be  pulled  out  for  access,  wiring 
connections  are  made  directly  to  the  pins  of  the  sockets. 
This  scheme  has  several  advantages. 

First,  the  cost  i*  low.  The  previous  construction 
technique  weed  printed-circuit  boards  for  mounting  the 
integrated  circuits.  Thu*  the  cost  of  mounting  the 
circuits  on  the  board  and  the  cost  of  the  board  itself 
vert  incurred. 

Second,  there  is  greater  flexibility  in  tne  location  of  a 
given  circuit  type,  with  the  integrated  circuit*  mounted 
on  printed-circuit  boards,  a  complete  board  consisting  of 
up  to  12  circuits  would  have  to  be  used  in  case*  where 
only  1  circuit  was  actually  needed. 
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Thirdly,  an  individual  DIP  can  dc  removed  and  replaced. 
This  is  i  great  aid  in  the  maintenance  of  a  device,  A 
DIP  with  a  suspect  circuit  can  quickly  be  removed  and 
replaced  by  on?  that  is  Known  to  be  cood, 

in  addition  to  the  techniques  of  hardware  realization  of  tne 
basic  logic  design,  many  other  details  of  the  hardware 
design  are  important. 

One  feature  that  the  hardware  must  provide  is  some  means 
of  aceess  to  both  the  integrated  circuits  and  tne  wiring 
••  this  feature  is  an  a&eoiute  necessity  during  initial 
checkout  and  is  an  aid  in  later  maintenance  and  change®. 

In  providing  acce*®  to  the  2Xternal  core,  the 
multiplex  switch  posed  a  particularly  difficult 
profiles,  since  JU  cables  connect  to  it,  in  order  t r 
allow  easy  access  to  this  unit,  the  mounting  system 
shown  in  ris.  III-t  was  developed, 

A  very  flexible  cable  is  used,  with  a  rather  elaborate 
method  of  strain  relief  and  cable  guidance.  Although 
the  original  mechanical  design  was  quite  expensive, 
requiring  about  3  months  of  a  design  draftsman's  time, 
past  experience  has  shown  the  difficulty  of 
maintaining  equipment  that  did  not  have  easy  access. 

To  date  this  design  cost  has  been  spreaa  over  several 
units  and  its  anticipated  use  in  future  unit*  will 
reduce  the  per-unit  cost  for  the  design.  The  expense 
of  hand-fabricating  the  parte  for  a  pull-out  drawer  is 
estimated  to  be  around  #300,  wnich  is  slightly  less 
than  »1  per  aoexet. 

In  the  recent  equipment,  light-emitting  diodes  (LEDa)  have 
been  used  instead  of  Incandescent  lights  for  panel 
indicators.  The  result*  have  been  very  satisfying. 

The  LSDs  have  a  higher  initial  cost  (about  *3  each)  than 
the  incandescent  lights  previously  used.  The  lights, 
however,  have  a  United  life  while  the  lifetime  of  the 
LEDa  is  essentially  infinite.  This  leads  to  essentially 
zero  maintenance  and  replacement  cost  for  the  lf.ds • 

This  long  service  life  also  means  that  the  expensive 
sockets  required  by  the  incandescent  units,  in  order  to 
facilitate  their  replacement,  can  be  eliminated, 
indicators  were  aountea  simply  by  drilling  holes  in  the 
front  panel  and  retaining  the  LEDs  with  RTV  silicone 
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rubber, 

A  further  cost  savin*  is  effected  since  these  lights  are 
driven  directly  from  the  logic*  savin?  not  only  the  coat 
of  the  drivers  themselves  but  also  the  coat  of  the  extra 
sockets  end  wiring  they  would  require, 

The  LZDa  have  a  relatively  narrow  viewing  ancle  and  less 
intensity  than  the  incar.deacent  lights,  but  we  nave  found 
them  entirely  satisfactory  in  use. 

c.  Typical  Construction  Coata 

A  fairly  careful  atudy  was  rude  of  the  actual  cost  of  the 
ARPA  Network  interface.  This  la  typical  of  the  type  of 
control  unit  *hat  la  now  oeim  built. 

Hardware  and  construction  --  tne  figures  are  given  on  a 
per-sccket  basis.  Technician  time  involved  in  construction 


ia  included, 

frame,  ccnnectors,  ic  aockets,  etc.  S3. 50 

Mounting  hardware  $2,00 

Compuv  time  32.ii0 

(preparing  wire-wrapping  control 
tape,  3j>  cents  per  wire  and  an 
average  of  6,8  wirea  per  socket) 

integrated  circuits  (average)  *2.oo 

Wire-wrapping  81,60 

(25  cents/wire  and  6,8  wires/socket ) 

Total  hardware  and  construction  *11.50 

(per  socket) 

Total  hardware  and  construction  *6900,00 

cost  for  Network  interface  (600 

sockets) 

Design 


The  design  cost  is  expressed  in  nan-days  for  a  deeign 
engineer. 

Initial  design  10  days 


71j 


Sec.  Ill 
HARDWARE  3Y3T2M 


Preparation  of  equation® 
Drawing®  and  documentation 
Final  assembly  and  debug 
Total 


10  days 
10  day® 

20  days 

50  days 
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A.  introduction 

The  central  focus  of  software  activity  at  the  Augmentation 
Research  Center  is  the  evolutionary  development  of  the  on-line 
System  (MS),  and  dunnf  the  contract  period  this  worn  has 
continued  in  the  spirit  of  bootstrapping  which  has  been 
consciously  applied  since  the  project's  inception,  in  addition  to 
RaDC  funding,  this  work  has  received  substantial  support  frcn  NASA 
under  Contract  NA51-7&97. 

The  original  version  of  NLS  (then  called  MTS  for  On-Line  Text 
System)  resided  first  in  a  CDC160A  computer  (Refs.  5  and  6);  it 
was  later  transferred  to  a  CPC3100  on  wnich  further  development 
took  place  (Fef .  7) . 

The  experience  and  tools  developed  with  tne  160a  and  3100 
systems  were  tnen  applied  to  the  design  and  construction  of  the 
present  ms,  which  provides  multi-console  service  from  an 
XDS9L0  computer  and  associated  special-purpose  hardware. 

As  has  been  true  throughout  its  development,  the  on-line  system 
is  now  being  used  principally  is  an  instrument  for  planning  and 
engineering  its  own  evolution  ana  as  a  tool  for  composing, 
editing,  and  publishing  documents  (such  as  this  report)  for 
distribution  outside  of  the  center. 

The  operation  and  evolution  of  Mf  takes  rlace  witnin  a  rich 
environment  of  software  systems,  many  of  which  were  created 
specifically  to  aid  in  its  development. 

►oat  basic  to  the  operation  of  MS  is  the  timesharing  system 
(T3S)  running  on  the  XDS9L0. 

TSS  was  originally  developed  by  Project  5ENIE  at  tne 
Berkeley  campus  of  the  university  of  California,  but 
responsibility  for  maintenance  of  the  ARC  version  presently 
lies  with  the  Center  itself. 

Each  user  runs  MS  as  a  subsystem  of  TSS  ard  consequently 
has  access  to  ether  TSS  subsystems  such  as  the  KD§  file 
system,  the  QED  text-handling  system,  and  the  DDT  symbolic 
debugging  system. 

work  done  on  TSS  during  tne  contract  period  is  described  in 
Section  IV-6. 


Preceding  page  blank 


77 


Sec.  iv 

software  system 


The  evolution  of  NLS  has  peer.  facilitated  rreatly  through  the 
use  of  an  extensive  collection  of  languages  and  their 
respective  compilers,  moat  of  which  were  developed  py  ARC 
itielf.  These  languages  and  compilers  are  discussed  in  Section 

xv-c. 

The  program  coae  for  NLS  resides  in  such  a  large  number  of 
files  that  compiling,  loading,  ana  debugging  the  system  t3  * 
complex  process,  to  make  these  operations  more  manageable,  a 
TSS  subsystem  called  NLS  UTILTY  (not  to  be  confused  with  the 
internal  utility  routines  of  NLS  itself)  has  been  constructed 
during  the  past  year,  a  description  of  nls  UTILTY  will  be 
found  in  Section  XV- G. 

During  the  contract  period  extensive  changes  have  been  made  to 
NLS,  both  in  user  service  features  and  in  internal  system 
organiiation. 

Development  was  begun  on  the  Typewriter-Oriented 
Documentation-A* d  system  (TOLAS),  which  will  make  much  of  the 
power  of  NLS  availaole  to  users  at  remote  locations  through 
hard-copy  terminals  such  as  Teletypes.  Implementation  of  TODAS 
is  one  of  the  major  steps  beinr  taken  in  setting  up  tne  Network 
Information  center  (NIC)  for  the  AkPA  Network. 

The  ability  to  examine  the  contents  of  NLS  files  has  been 
enhanced  oy  the  implementation  of  a  powerful  set  of  JUMP 
commands,  including  provision  for  jumping  between  files  using 
file  links,  (a  file  link  is  simply  an  occurrence  of  a  file 
name,  properly  embedded  within  the  text  of  another  file.) 

Facilities  have  been  provided  to  enable  the  NLS  user  to  request 
that  each  file  statement  displayed  be  tagged  with  the  initials 
of  the  perr  who  last  modified  that  statement  alor.j  with  the 
date  of  mooif ieation. 

Conventions  for  handling  keyset  input  have  been  changed  so  that 
the  31  input  characters  may  be  interpreted  in  any  of  four  cases 
(lover  case,  upper  case,  numbers  and  special  characters,  and 
Viswspjtcs i  •  The  case  is  determined  by  concurrent  input  from 
the  center  and  left  pushbuttons  on  the  mouse  (lower  case  is  the 
normal  case) , 

Commands  have  been  added  to  enable  the  user  to  set  any  text 
entity  in  a  variety  of  type  styles  (upper  case,  lower  case, 
italic,  boldface,  flickering,  underlined),  and  the 
display-generation  routines  nave  been  modified  so  as  to  display 
text  in  the  specified  forms. 
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A  limited  output-processor  capability  has  been  orovided  so  that 
programs  maintained  as  NLS  text  files  can  De  compiled  directly 
from  NLS  (rather  than  having  to  be  converted  to  UED  files 
first)  • 

Several  other  new  features  have  been  added  to  NLS,  including 
the  following! 

(1)  Vector  package  --  a  oasic  graphics  capability 
permitting  the  user  to  insert  simple  line  drawings  into  a 
file 

(2)  Keyword  system  --  a  means  of  information  retrieval 
working  upon  special  information  inserted  in  a  file,  with 
user  control  over  categories  of  information  to  be  retrieved 

(3)  Calculator  pecxage  --  a  calculation  capability  for  the 
NLS  user,  providing  four  storage  registers  and  an 
accumulator  ADD,  SUBTRACT,  MULTIPLY,  and  DIVIDE  operations, 
and  the  ability  to  select  operand  numbers  from  file  text  and 
insert  results  oacx  into  the  file  text 

U)  substitute  command  --  causes  automatic  substitution  of 
one  user-specified  character  string  for  another,  throughout 
some  user-specified  portion  of  the  file 

(5)  File  cleanup  and  compaction  --  automatic 
user-controlled  correction  of  certain  Kinds  of  system-caused 
errors  in  a  file,  and  reduction  of  the  storage  needed  for 
the  file  by  means  of  special  garbage-collection  methods 

(6)  output  of  NLS  files  to  microfilm  (via  an  out-of-house 
facility) . 

in  addition,  the  overlay  structure  of  NLS  has  been  reorganized 
to  provide  room  for  growth  of  the  system,  and  numerous  ether 
internal  system  changes  have  been  made  to  provide  improved 
service  and  reliability. 

An  overview  of  the  current  structure  of  NLS  is  provided  in 
Section  IV-E,  and  a  more  detailed  description  will  be  found  in 
Appendix  D. 

Descriptions  of  earlier  work  on  the  design  and  development 
cf  NLS  for  the  XD39L0  are  contained  in  Refs.  7,  dt,  and  9, 

0\/her  software  development  activities  covered  'n  this  report 
include  preparations  for  interfacing  with  the  ARPA  Network  (see 
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Section  IV-F),  and  a  simulation  study  of  factors  affecting  the 
response  tine  of  the  timesharing  system  when  a  number  of  NLS  users 
ere  being  served  Uee  Section  3V-D). 

8,  The  Timesharing  system  (TSS) 

The  support  of  new  nardware  and  improved  response  to  the  NLS  user 
are  the  two  main  reasons  for  the  expenditure  of  effort  on  the 
timesharing  system  (TSS). 

1.  Disc  Support 

The  Bryant  disc  device  was  recieved  in  August  1966.  This 
device  has  the  capability  of  storing  32  million  2U-oit  words, 
with  the  acceptance  of  tni*  device,  a  file-storage  program 
called  KDF  was  implemented  to  provide  users  witn  a  means  of 
storing  information.  The  earliest  form  of  KDF  orerated 
essentially  independently  of  tne  TSS  I/O  ntndling  system,  A 
later  version  was  integrated  with  tne  TSS  system,  and  made  all 
accesses  to  the  disc  via  calls  on  the  supervisor. 

During  late  1966  and  the  early  months  of  1969*  the  TSS  system 

wad  extensively  modified  to  include  scratch  disc  files.  These 
files  are  handled  by  the  same  calls  on  tne  supervisor  as  are 

the  drum  files.  In  this  way,  the  disc  files  have  the 

flexibility  of  the  drum  files  as  well  as  freeing  tne  user  from 
KDF 's  restrictions  on  the  numoer  and  sire  of  files.  Pise 
scratch  files  may  be  used  for  all  the  same  functions  as  drum 
files,  while  KDF  is  used  primarily  for  storage.  The  disc  file 
space  is  pooled  by  all  the  users  and  thus  has  tne  additional 
advantage  of  more  economical  use  of  this  space  than  is  possible 
under  KDF.  The  development  of  improved  garbage-collection 
facilities  permitted  the  use  of  "permanent"  scratch  files  on 
the  disc  for  longer-term  storage  of  heavily  used  files. 

2.  Magnetic  Tape  support 

•The  new  TSS  developed  in  late  1966  and  early  1969  incorporated 
the  direct  tape  I/O  pacKage,  which  permitted  more  efficient  use 
of  tape  files.  The  increased  speed  and  efficiency  of  the  tape 
files  made  it  more  practical  to  copy  information  stored  under 
KDF  to  magnetic  tape,  thus  protecting  this  information  from 
loss  in  the  event  of  serious  disc  failure. 

Further  vorK  has  been  done  to  improve  the  reliability  and  speed 
of  access  of  tape  files,  as  required  by  the  Arcnive/ Journal 
system  (see  Appendix  BI.  The  magnetic  tapes  serve  as  the  main 
storage  facility  for  most  of  the  older  or  less  used  files,  and 
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thus  relieve  KD5  of  the  burden  of  storing  these  files. 

3.  External  core 

The  inter-core  controller  (ICC)  and  the  external  core  memory 
became  available  in  early  1570.  Several  supervisor  calls  have 
been  written  to  a1 low  the  user  to  acces  .  this  device* 

TSS  allows  a  user  to  obtain  up  to  id  thousand  words  of 
external  core  memory,  and  maintains  tables  vnich  perform  c 
limited  relabeling  function  between  user-provided  addresses 
and  physical  addresses. 

other  calls  permit  tne  user  to  make  data  transfers  via  ICC 
between  external  core  and  9U0  memory  and  vice  versa,  as  well 
as  transfers  from  one  area  of  external  cere  memory  to 
another  area  of  external  ~ore  memory,  or  from  one  area  of 
9k0  memory  to  another  ar<--*  ux  9U0  memory, 

kr  Other  Devices 

A  program  has  oeen  written  to  permit  the  queuein*  of  print 
files.  This  program  allows  tne  user  to  place  his  file  in  a 
print  queue  and  continue  on  to  other  tasks.  The  queueing 
program  informs  the  user  of  nis  file* a  position  in  the  printer 
queue  and  the  approximate  amount  of  material  to  be  output 
before  his  file  will  be  completed. 

Minor  additions  and  modifications  to  the  TSS  system  have  Deen 
made  to  support  the  Data  products  printer  and  several  new 
Teletype  and  typewriter-style  terminals, 

5.  Research  on  Scheduling  Algorithms 

Tne  system  simulation  (discussed  in  Sec.  iv-D)  nas  indicated 
^hat  system  response  to  the  NLS  user  might  oe  improved  by 
redesign  of  the  scheduling  algorithm.  Toward  this  end,  we  hive 
experimented  with  several  modifications  to  the  seneduling 
alfcritnm,  particulary  with  respect  to  the  assignment  of 
priorities  and  the  queue-assignment  schemes. 

One  such  experiment  consisted  of  assigning  a  special  queue  for 
NiS  users,  giving  them  higher  priority  than  other  I/C  users  or 
users  who  place  heavy  computational  loads  on  the  system. 

This  queue  measurably  improved  tne  response,  for  the  Nis 
user,  but  so  impaired  the  response  to  other  users  tnat  in 
some  cases  it  was  not  possible  to  run  the  executive 
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program* . 

Since  tnat  early  trial,  we  nave  implemented  a  new  scheme 
that  favors  NLS  users  and  any  other  users  who  are  engaged  in 
frequent  out  short  I/O  processes.  The  improvement  nas  not 
seen  as  noticeaPle  as  with  tne  earlier  scheme,  Put  has  not 
resulted  in  such  severe  impairment  of  service  to  other 
user30  This  algorithm  tenas  to  favor  the  user  who  is 
engaged  in  editing  text,  as  opposed  to  tne  user  who  ia  doing 
a  great  deal  of  file  manipulation.  Another  part  of  this 
effort  has  snown  that  another  queue  was  not  serving  a  u&eful 
purpose,  and  tnis  queue  has  since  oeen  discarded. 

6.  Genera*. 

Much  work  has  peen  done  in  restructuring  tne  TS3  system  to 
provide  space  for  accommodating  the  storage  requirements  of  the 
AftP.i  Network,  Several  routines  hive  ceen  rewritten  and  moved 
to  the  Executive,  and  others  have  peen  moved  t<*  nonresident 
rages.  in  this  w*y,  several  hundred  core  locations  have  Peen 
made  available  for  Network  use. 

Because  of  the  greatly  reduced  level  of  effort  of  Project  GEMh 
at  UC  Berkeley,  it  has  become  necessary  for  us  to  further  the 
development  of  TSS  essentially  independently • 

C.  Compilers 

1,  introduction 

The  development  cf  NLS  has  been  greatly  facilitated  through  the 
use  of  a  powerful  complement  of  languages  and  compilers,  most 
of  which  were  designed  at  ARC, 

The  languages  used  range  in  generality  from  the  NARP 
assembly  language  through  a  collection  of  special-purpose 
language;  (SPL's)  unique  to  NLS  implementation. 

Having  such  flexible  set  of  languages  from  which  to  choose 
makes  it  possible  tc  select  for  each  programming  task  the 
language  in  which  the  desired  operations  cm  be  expressed 
most  naturally. 

t.  NARP 

There  are  a  few  parts  of  nls  that  can  ce  most  conveniently 
coded  ir,  asaeroiy  language  (e,g.,  the  aata  page  and  the 
display-buffer  page),  and  for  these  the  NARP  assembly 
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language  is  used. 

Also,  for  historical  reasons,  the  timesharing  system  (TSS) 
and  most  of  it?  subsystems  (e.g.,  KDF  and  DDT)  are  coded  in 
NAUR. 

The  HARP  assembler  is  based  on  another  assembler,  AKPAS; 
both  of  these  languages  were  produced  by  Project  GENIE  for 
use  In  the  development  of  TSS  (see  Refs,  10  and  11). 

fc,  Momo 

MQLSkO  (or  simply  MOD  is  a  machine-oriented  language  for 
the  XDS9 ko  and  was  created  by  ARC  to  aid  in  the  programming 
Of  NLS. 

MOL  combines  the  flexibility  of  assembly  language  with  the 
algorithmic  clarity  cf  higher-level  procedure-oriented 
languages.  Much  of  NLS  ia  cooed  in  MOL, 

The  original  version  of  M0L9UC  is  described  in  Ref.  12. 
while  this  report  contains  a  brief  oescription  of  the 
current  version. 

During  the  contract  period  MOL  has  been  substantially 
rewritten  to  improve  its  performance  and  provide  new 
programming  features. 

Ihe  current  mol  compiler  was  produced  using  the  new 
version,  of  Tree  Meta  (desc~'  eo  below);  consequently,  tne 
hOL  compiler  new  generates  Dinary  machine  code  directly 
rather  than  producing  assenciy-language  code. 

as  a  result  of  this  change,  assembly-language 
instructions  are  now  treated  as  built-in  functions, 
whereas  previously  they  w-re  handled  using  escape 
conventions  which  provided  for  tnem  to  be  passed 
directly  into  the  output  stream  without  translation. 

optional  mechanisms  have  oeer.  added  to  facilitate  the 
writing  of  reentrant  code,  ujing  a  software  stack  for 
procedure  calls  and  for  storage  of  local  temporaries. 

The  syntax  for  procedure  calls  has  ceen  modified  so  that 
an  entire  NLS  file  link  may  be  used  in  place  of  the 
procedure  name  alone  - 

The  presence  of  tne  file  liru  augments  »  programmer's 
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ability  to  study  a  complex  system  of  programs 
occupying  several  nis  files,  by  m  a  <  i  n  g  it  very  easy 
for  nim  to  k1ump  from  a  file  containing  a  reference  to 
some  procedure  into  the  file  containing  the  procedure 
itself.  In  compiling  a  program  only  tne  name  part  of 
the  file  link  ii  used;  tne  rest  of  the  link  is  treated 
as  commentary  inior-nation,  a^ce  it  is  irrelevant  to 
tne  compilation  process. 

Tree  Meta 

Tree  Meta  is  a  compiler-compiler  developed  at  ARC;  it  is 
used  to  produce  compilers  for  MOL  and  all  tne 
special-purpose  lareuages  (and  for  itself  as  well)  „ 

Section  iv-C-2  contains  a  brief  overview  of  the  current 
version  of  Tree  beta,  and  a  more  detailed  description  ia 
in  preparation  for  release  as  a  separate  report. 

(Pending  publication  of  tne  Tree  Meta  document,  a 
description  more  comolete  than  that  contained  in  the 
present  report  can  be  found  in  Ref.  6.) 

During  the  contract  period,  the  only  ma^or  change  to  the 
Tree  Mrta  system  was  a  modification  to  the  basic  way  in 
which  compilers  produced  oy  Tree  Met£  generate  code. 

Compilers  produced  py  Tree  meta  used  to  translate  a 
given  source  language  into  assembly  language,  which 
then  had  to  be  translated  by  tne  na*P  assembler  to 
obtain  machine  code. 

with  the  new  Tree  Meta,  the  compilers  generate  machine 
code  directly,  thur  eliminating  one  step  of  the 
translation  process. 

The  3PL's 

I -«v  of  the  higher-level  operations  of  NLS  are  carried 
out  by  programs  written  in  one  of  a  set  of 
special-purpose  languages  (SPL'a).  Each  of  these 
languages  is  translated  into  machine  code  by  a  compile:’ 
produced  witn  the  Tree  Meta  system. 

Each  SPL  represents  an  attempt  to  formalize  a  particular 
function  of  hi, 3,  aiming  at  a  syntax  appropriate  to  the 
aata  base  tna  operations  required  for  NLS,  while  at  the 
same  time  embodying  the  potential  and  pecu.i  iarities  of 
'he  XDS9UQ  computer. 
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The  four  bPL’a  currently  in  use  are  the  input-f eedoack 
language,  the  structure-manipulation  language,  the 
content-analysis  language,  and  the  string-construction 

language. 

Detailed  descriptions  of  the  SPL's  will  be  found  in 
Appendix  D  of  this  report  as  well  as  in  Ref.  6, 

Although  extensive  changes  in  the  SPL's  are  planned  for 
the  near  future,  no  basic  conceptual  changes  were  made 
during  the  contract  period. 

7,  Tree  Meta?  a  Compiler-writing  System 

A  compiler-writing  system  was  implemented  within  the  AxC  for 
use  in  writing  compilers  for  tne  M0LS10  language  and  the 
SDecial-purpose  languages  (SPLs)  used  in  implementing  NL3 • 

The  Tree  Meta  language  allows  one  to  concisely  specify  the 
syntax  of  a  language,  in  a  notation  similar  to  bacKus-Naur 
Form.  Embedded  v .tnin  this  syntax  specification  are  rules 
and  directives  describing  exactly  now  the  compilation  of  a 
program  written  in  the  language  is  to  take  place. 

The  Tree  Meta  compiler  reads  a  textual  program  written  in 
the  Tree  Meta  language,  and  directly  produces  a  binary 
machine-language  program  which  is  a  compiler  for  tne 
specified  language.  The  new  compiler  is  then  capacle  of 
reading  a  textual  program  in  the  specified  language  and 
producing  a  binary  program  according  to  the  compilation 
rules  embodied  in  tne  comciler. 

Tree  Meta  is  expressed  in  its  own  language,  and  is  thus 
self-compiling.  The  current  version  has  been  produced  from 
previous,  more  limited  versions  by  the  process  of 
bootstrapping • 

Tree  Mtta  has  proven  to  be  a  particularly  valuable  tool  in 
system  development  at  ARC,  because  of  the  experimental  nature 
of  the  development  being  done  here. 

perhaps  the  most  valuable  feature  of  Tree  Meta  is  ite  ease 
of  use,  a  complete  compiler  description  is  contair.ee  in  a 
tingle  text  file  and  is  readily  edited  and  recompiled,  a 
change  in  a  compiler  can  oe  tried  in  two  or  three  minutes. 
This  allows  experimentation  that  otherwise  would  be  too 
time-consuming,  and  makes  tne  debugging  of  language 
specif icationa  quite  fast,  mis  flexibility  is  very 
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important  when  a  language  la  being  developed  --  as  opposed 
to  having  been  preapecified  and  fixed  in  ita  definition. 

The  relatively  simple  Tree  Meta  notation  describes  a 
language  precisely,  and  anyone  familiar  with  the  notation 
can  see  what  the  syntax  is.  The  code  for  the  compiler  is 
also  the  formal  definition  of  the  language  to  be  compiled. 

Al*<o,  since  the  source  ccce  for  tne  Tree  Meta  compiler  is 
simply  a  description  of  the  Tree  aeta  compiler  expressed  in 
tne  Tree  Meta  language  itself,  it  is  possible  to  produce  a 
new  version  of  Tree  Meta  merely  by  editing  and  recompiling 
this  description. 

The  Tree  Meta  system  consists  of  this  symbolic  description,  the 
Tree  Meta  compiler,  and  a  library  of  support  routines  in  MOl. 
The  support  routines  perform  functions  such  as  input/output  and 
symbol-storage  operations. 

The  Tree  Meta  compiler  is  relatively  fast.  It  compiles  itself 
in  about  30  seconds  from  about  a  pages  of  text  input.  The 
compiled  program  is  about  12  thousand  words  of  memory, 
including  tables  and  storage  areas, 

Yn  the  formalism  of  Tree  Meta,  a  compiler  consists  of  (1)  parse 
rules,  which  parse  the  input  in  a  top-down  manner  and  nuild  a 
tree  structure,  and  (2)  unparse  rules,  which  ther.  test  the  tree 
structure  and  produce  machine  code.  The  tree  consists  of 
symbols  taken  from  the  input,  values  and  flags  inserted  in  the 
tree  by  the  oarse  rules,  and  nonterminal  nodes  that  correspond 
to  unparse  rules. 

The  parse  rules  test  the  input  stream  to  identify  the 
constructs  it  contains. 

For  example,  to  test  the  input  stream  for  an  assignment 
statement,  tne  following  rule  called  "assign"  might  be 
used. 

assign  *  identifier  "*>"  expression  satore/2 ]\ 

This  parse  rule  defines  an  "assign"  to  be  an  "identifier" 
followed  by  a  left-arrow  followed  by  an  "expression," 
where  "identifier"  and  "expression"  would  be  defined  by 
other  parse  rules. 

If  tne  input  stream  is  matched  oy  tr.is  rule,  a  node  will 
be  constructed  in  the  tree  and  tagged  with  the  name 
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'‘•tore. M 

This  node  will  have  two  nodes  under  it,  corresponding 
to  "identifier"  and  "expression,"  respectively. 

The  unparse  rules  are  executed  beginning  with  the  last  node 
built  into  the  tree.  The  node  names  in  the  tree  determine 
which  rules  will  be  invoked  to  compile  code  from  that  node 
of  the  tree. 

In  the  example  above,  the  unparse  rule  named  "store"  will 
test  the  node  for  several  different  forms  and  output  code 
depending  on  the  form,  a  test  might  be 

/’identifier,  add /*1,-;; 

This  test  reads  as  follovsi  The  "store"  node  must  have  two 
nodes  under  it.  The  first  node  must  be  an  identifier.  The 
second  must  be  a  node  named  "add,"  which  has  two  noaes  under 
it.  Furthermore,  the  first  node  of  "add"  must  be  exactly 
the  same  as  the  first  node  of  "store."  Tnis  test  would  be 
satisfied  oy  input  of  the  form 

x  «■  x  ♦  (anything) 

Another  test  night  be 

l identifier,  add  Ml# *l"J] 

which  is  the  same  but  with  the  additional  requirement  tnat 
the  second  node  of  "add"  must  be  tne  number  "1",  This  is 
checking  for  input  of  the  form 

y  *  y  ♦  1 

The  unparse  rule  "store"  night  begin? 

store  /’identifier,  add  Ml,  *1"))  ■>  MIN  *1,  ; 

/identifier, add/*i,-y;  ■>  _daM2:2/  ADM  #i,  j 

If  the  test  on  the  first  line  succeeds,  "store"  produces  a 
single  memory-increment  instruction,  MIN,  operating  on  the 
memory  word  addressed  by  the  identifier  (the  first  node  of 
"store"),  otherwise,  if  the  second  test  succeeds,  an 
unparse  rule  named  "Ida"  is  called  with  the  second  node  of 
"add,"  as  argument  in  order  to  produce  code  tc  load  the 
A-regiater.  Then  an  add- to-mcnory  instruction  is  produced. 
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again  ooerating  on  the  memory  wore  addressed  oy  the 
identifier.  Tne  rule  "store"  would  then  continue  oy  testing 
for  other  forms  of  expressions,  until  all  legal  forms  have 
been  taken  care  of. 

The  tree  serves  as  an  intermediate  form  of  the  orogram  --  a 
form  which  facilitates  extensive  testing  by  the  unparse 
rules,  and  which  usually  contains  no  redundant  information. 
The  compiler  author  determines  the  forms  of  the  trees 
completely  when  writing  the  compiler.  His  i.ujenuity  in 
determining  the  tree  forms  and  compilation  schemes  is 
generally  not  restricted  by  tne  Tree  Meta  language. 

Symbols  (which  may  be  of  arbitrary  length)  are  read  from  the 
input  and  kept  in  a  symbol-storage  area  where  they  are 
referenced  via  a  hasn  table,  symbols  may  also  be  created 
and  entered  into  the  symbol-storage  area  by  the  compiler. 
Each  symbol  has  a  2t-bit  value  as  well  as  2k  attribute  bits. 
The  meanings  for  most  of  tne  attribute  cits  may  be  defined 
by  the  compiler  writer,  and  symbol  values  and  attributes  ma 
be  set,  reset,  and  tested  during  the  running  of  the 
compiler. 

The  output  from  any  Tree  met a  generated  compiler  is  a 
relocatable  binary  file,  produced  m  tne  proper  form  for  DDT 
(the  loader  and  debugging  system).  This  binary  file 
includes  the  symbols  from  tne  program,  so  that  programs  can 
be  debugged  symbolically . 

3,  A  Machine-Oriented  Language,  M0L9L0 

In  spite  of  the  quite  sophisticated  understanding  of  compilers 
and  compiler-compilers  in  computer  science,  assembly  language 
is  still  used  for  the  bulk  of  system  programming. 

ASQ  has  used  a  machine-oriented  language  as  a  replacement  for 
assembly  language  in  the  writing  of  system  programs.  The 
machine-oriented  language,  M0L9k0  (or  simply  MMCLM)  offers  the 
power  of  an  assembly  language  wr.ile  providing  the  algorithmic 
clarity  found  only  in  a  higher-level  language. 

A  machine-oriented  language  is  designed  to  give  the 
programmer  a  block-structured  language  with  many  of  the 
usual  associated  features,  such  as  conditional  and  iterative 
statements,  subscripting,  and  aritnmetic  expressions. 

At  the  same  tine,  the  language  designed  to  reflect  the 
idiosyncrasies  of  the  actual  machine  on  which  the  programmer 
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is  writing  nia  programs.  to  this  end,  special  constructs 
are  incorporated  in  the  language  wnich  allow  the  programmer 
to  have  some  control  over  the  code  which  is  produced  and  the 
manner  in  which  the  central  registers  are  uatu. 

The  idea  of  a  macnine-oriented  language  is  not  new. 

Erwin  Book  of  system  Development  Corporation  first  developed 
an  MOD  for  the  Q-32  ana  later  an  MOL  for  the  I bh  360. 

Niiclaua  wirtft'a  PL-360  was  an  MOL  used  to  implement  a 
version  of  ALGOL  on  the  360. 

An  MOL  for  tne  XD99uO  was  a  early  development  of  ARC,  ar.d 
was  used  in  the  initial  implementation  of  NLS,  A  modified 
version  of  this  language,  developed  vitn  Tree  Meta,  is  the 
MOL  descriDcd  in  this  section. 

The  general  design  of  M0L9LQ  is  actually  machine-independent. 
Only  the  inclusion  of  special  logical  forms  and  Puilt-in 
functions  gives  the  ianguare  a  specific  orientation  towards  a 
particular  machine.  Thus  it  may  serve  as  a  Dasis  from  which 
MOLi  for  other  machines  nay  he  derived  oy  suostltuting  other 
logical  forms  and  other  built-in  functions. 

Among  the  distinguishing  factors  of  any  programming  language 
are  the  means  provided  for  referencing  information  and  for 
controlling  the  flow  of  execution. 

in  M0L9U0  tne  means  for  referencing  information  *re  as  complete 
as  in  an  assembly  language. 

The  central  registers  of  the  machine  are  represented  as 
basic  elements  in  the  syntax  of  the  language.  Thus  M.AF" 
stands  for  tne  A-register,  ".ah*1'’  causes  a  l  to  ce  loaded 
into  tne  A-register,  and  "X^.AR"  causes  the  contents  of  the 
A-register  to  oe  stored  in  location  x. 

Assignment  ia  made  one  of  the  binary  operations  that  can 
occur  in  an  arithmetic  expression. 

This  allow:  the  programmer  to  refer  to  the  value  of 
subexpressions  in  a  very  straightforward  manner. 

For  example,  one  can  write  "K<*  ( i^n)  *10;  or  "k«-10*  j*n; " 
instead  of  "j«-n;  k  +  .ar  ♦  10;".  While  ooth  forms  would 
result  in  the  same  code,  the  use  of  assignment  as  a 
binary  operator  avoids  tne  explicit  reference  to  the 
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A-register . 

An  ipo strophe  followed  by  a  single  cnaraeter  ray  be  used 
interchangeably  with  the  numerical  code  for  that  character* 

This  can  be  of  great  value  in  clarifying  the  intent  of  a 
test.  For  example,  assume  that  the  numerical  code  for  g 
Question  marx  is  16.  Then  a  test  for  a  question  mark  may 
be  made  by  "■'?K  rather  than  the  less  informative  "«16". 

Tne  term  "literal"  will  be  used  to  denote  a  term  that  can 
be  either  a  number  or  an  apostrophe  followed  by  a  single 
character. 

Two  mode*  of  referencing  information  are  provided  to  give 
addressing  completeness.  These  moaes  are  similar  to  the 
"left-hand  value"  and  "right-hand  value"  concepts  found  in 
CPL  and  BCPL. 

The  modes  are  differentiated  by  the  presence  or  absence  of  a 
dollar  sign  in  front  of  the  reference.  The  former  will  be 
caned  "dollar  mode,"  and  the  latter  "normal  mode."  The 
values  referenced  by  identifiers,  literals,  and  strings  in 
the  two  model  are  as  follows! 

(1)  Normal  Mode 

(a)  identifieri  contents  oi  the  cell  whose  address  is 
tne  value  of  the  identifier. 

(b)  Literal:  the  numerical  value  of  the  literal 

(c)  String!  contents  of  the  first  cell  used  to  hold 
tne  string 

(2)  Dollar  Mode 

(a)  Identifier!  the  value  of  the  identifier  (i.e., 
the  address  of  a  memory  cell) 

(b)  Literal:  contents  of  the  cell  whose  address 
equals  the  value  of  the  literal 

(c)  string!  the  adaress  of  the  first  cell  used  to 
hold  the  string. 

The  tern  "value  of  an  identifier"  as  used  here  is  equivalent 
to  the  left-hand  value  of  an  identifier  in  C?L. 
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Thus  if  cell  kOO  corresponds  to  the  identifier  k  or  if  k 
has  been  set  equal  to  nQO,  as  in  an  EQU  statement  of  an 
esaenbler,  then  the  value  of  k  is  kOO.  It  might  also  be 
called  tne  synod-table  value  of  the  identifier. 

Notice  that  the  normal  mode  of  an  identifier  or  literal 
corresponds  to  usage  in  problen-oriented  languages. 

Indexing  and  indirection  are  allowed  where  appreDriate  vith 
the  above  forms. 

Indexing  is  specified  by  following  the  reference  with  an 
expression  enclosed  in  square  brackets,  while  indirection 
is  specified  by  enclosing  the  entire  reference  in  square 
brackets. 

The  syntax  disallows  such  dubious  constructs  as  indexing 
with  a  literal  or  indirection  with  a  string.  The 
following  shows  in  which  cases  indexing  and/or 
indirection  arw  allowed. 

(1)  Normal  mode 

(a)  Identifier:  indexing  and  indirection 

(b)  Literal:  neither 

(c)  String:  indexing 

(2)  Lollar  mode 

(a)  Identifier:  neither 

(b)  Literal:  indexing  and  indirection 

(c)  String:  neither. 

The  means  mentioned  above  make  an  MOL  at  least  as  powerful  as 
an  assembly  language  in  referencing  information,  in  specifying 
the  control  of  activation  flow,  an  riOL  is  clearly  superior. 

Flow  cf  activation  ia  determined  by  the  results  of  logical 
tests,  it  is  in  the  clarity  of  expression  of  these  logical 
tests  that  an  MOL  is  particularly  valuable. 

TO  facilitate  congruence  between  program  construction  and 
the  idiosyncrasies  of  a  given  machine,  the  syntax  of  an  MCL 
should  contain  constructs  that  reflect  the  logical  tests 
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made  possible  by  the  instruction  set. 

For  example,  the  XDS9lit  has  an  instruction  that  skips  if 
the  contents  of  the  A-register  and  the  effective  address 
do  not  have  ones  in  any  corresponding  bit  positions. 

Thus  M0L9ii0  has  a  logical  construct  Msuml  C6  sum2"  which 
is  true  if  and  only  if  sum  has  a  one  in  a  common  bit 
position  with  Sun2, 

in  addition  to  logical  constructs,  there  must  be  means  to 
specify  the  repeated  execution  of  a  i iven  statement  and  the 
choice  for  execution  of  a  particular  statement  out  of 
several.  The  main  constructs  for  repetition  in  MCL9>iO  are 
the  LOOP  and  while  statements. 

The  LOOP  statement  is  cased  on  a  suggestion  of  r.nuth.  It 
provides  the  most  general  possible  form  of  control  of 
repetition. 

The  statement  following  the  word  M LOOP"  is  executed 
repeatedly  until  an  "EXIT11  statement  embedded  within 
the  loop  is  executed. 

Execution  of  an  EXIT  statement  causes  control  to  leave 
the  innermost  loop  containing  it. 

There  may  he  an  arbitrary  number  of  EXIT  statements 
within  a  LOOP,  placed  arbitrarily,  and  nested  within 
blocks  to  an  arbitrary  level. 

The  while  statement  simply  serves  as  a  convenient 
alternative  way  of  writing  a  commonly  used  fern  of  the 
LOOP  statement,  namely  the  form  with  a  single  EXIT 
occurring  at  the  start  of  the  LOOP. 

Selective  execution  is  orovided  by  IF  and  CASE  statements. 

The  IF  statement  is  tne  standard  Algol-like  IF  with  an 
optional  FLOE  part. 

Since  the  9h0  uses  skip  instructions  for  logical 
tests,  it  is  possible  to  optimize  tne  branches 
required  if  there  is  no  false  part  and  the  true  part 
consists  of  a  single  instruction.  This  is  done  if  the 
user  writes  "  D  0  -  ?•  I N  G  L  E "  instead  of  "THEN", 

The  CASE  statement  corresponds  to  a  special  form  of  the 
I  Jr  statement  in  which  the  case  is  selected  for  execution 
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according  to  the  class  into  which  an  expression  fail3. 

The  syntax  is  roughly 

"CASE”  expression  "OK"  sequence  of  cases  "tNFCASE" 
statement 

where  each  case  in  the  sequence  consists  of  one  cr  more 
tests  followed  by  a  statement., 

A  test  consists  of  a  binary-relation  symbol  followed  by 
the  right-hano  side  of  the  binary  relation.  The  test  is 
true  if  the  binary  relation  formed  by  using  the 
expression  at  the  head  of  the  case  as  the  left-hand  side 
i*  satisfied. 

The  first  case  with  a  true  test  is  the  one  executed.  If 
none  of  the  tests  ire  true,  then  the  statement  following 
"ENDCASE"  is  executed. 

A  common  use  of  the  CASi  statement  is  in  determining  the 
proper  response  to  a  character  input  from  a  terminal, 

finally,  M0L9U0  permits  the  use  of  machine  instructions  as 
built-in  functions.  The  syntax  of  such  a  built-in  is 
roughly 

function-name  address-reference  actual-arguments. 

The  function  name  is  simply  the  standard  mnemonic  operation 
code  for  the  instruction. 

The  address  reference  is  optional;  if  present,  it  may  pe  an 
identifier,  literal,  or  string,  with  optional  indexing  or 
indirection. 

The  actual  arguments  are  also  optional;  if  present,  they 
consist  of  a  sequence  of  expre  tions  to  pe  loaded  into 
registers,  separated  by  commas  and  enclosed  in  parentheses. 

such  a  cuilt-in  function  may  be  used  either  as  a  statement 
by  itself  or  as  a  primary  in  »n  arithmetic  expression. 

It  should  be  clear  that  this  allows  the  programmer  complete 
access  to  the  instruction  set  of  the  macnine  and  gives  the 
opportunity  to  produce  as  efficient  code  as  could  oe  cone  m 
assembly  language  (where  this  Is  deemed  necessary). 

Experience  at  arc  rue  shewn  that  machine-oriented  languages  are 
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an  attractive  medium  for  systems  programming,  They  permit 
efficient  code,  unrestricted  data  structures,  ana  complete  use 
Of  tne  machine  instruction  set,  giving  a  flexibility  usually 
associated  onl>  with  assembly  languages,  while  still  providing 
the  algorithmic  clarity  of  higher-level  languages. 

D.  Response  Studies 

we  conducted  a  study  of  factors  affectirg  tne  response  time  rf  tne 
timesharing  system  on  our  XD$9liO  computer,  which  serves  a  number 
of  NLS  display  tei ..  n&ls  reouiring  very  rapid  response  to  user 
actions.  The  method  of  approach  was  a  highly  parameterized 
simulation  of  the  tinu  'arir.g  system,  whicn  permits  experimental 
evaluation  of  various  possible  methods  of  improving  system 
response  time.  A  summary  of  the  approach  and  the  results  is  given 
here. 

1.  Objectives  of  the  studv 

Altnouen  this  study  vet  conducted  specifically  on  the 
timesharing  system  ir.  use  at  AkC,  it  is  of  general  interest  (l) 
because  of  the  unique  method  of  approach,  which  permits  easy 
implementation  of  results,  and  (2)  because  it  nay  be  expected 
that  systems  resembling  NL3  m  some  ways  will  be  coming  into 
more  gener  *  use  ir.  the  future.  The  -rineipal  characteristic 
of  HL5  that  affects  the  behavior  of  the  timesharing  system  i« 
its  dependence  on  fast,  highly  interactive  operation  of  display 
terminals,  and  computer  technology  is  already  responding  to  a 
strong  demand  for  this  Kind  of  user  interface. 

It  should  De  emphasiz'd  that  we  are  dealing  here  with  the  time 
required  for  the  system  to  respond  to  individual  commands  from 
interactive  users,  and  not  with  the  system's  speed  in 
performing  large  numerical"Comput».tion  tasks. 

Interactive  display  usage  for  text  manipulation,  if  it  is  to  be 
really  effective  from  the  user  s  point  of  view,  requires  much 
shorter  response  times  than  have  normally  been  considered 
satisfactory  for  timesharing  systems-  in  the  case  of  NlS,  the 
desired  respens'  time  for  a  typical  command  is  a  fraction  of  a 
second  -•  delay?  mo^e  than  a  second  can  seriously  impair  the 
user'*  tasx  perf<  unct  if  *hey  occur  too  frequently.  By 
contrast,  the  response  of  a  less  interactive  system  such  as 
TODAS,  which  is  not  designed  around  an  interactive  display,  is 
considered  satisfactory  if  tn  *vpicai  delay  ir.  executing  a 
simple  command  is  no  more  thar.  few  second?. 

The  immediate  goal  of  the  current  study  is  to  develop  an 
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understanding  of  tne  interrelated  factors  affecting  the 
response  time  of  ARC 1  s  timesharing  system  and  to  identify 
pos sibilities  for  modifying  the  hardware  and  software  of  the 
aysten  so  as  to  improve  the  responsiveness  of  this  system. 

2,  Approach 

The  approach  taken  v»s  to  write  a  simulation  of  the  timesharing 
system  ( T3S )  operating  on  the  XDSSliO.  The  simulation 
incorporates  the  scheduling  and  swapping  algorithms  of  TSS  and 
allows  changing  of  parameters  to  represent  various  facility 
configurations  and  usages. 

This  allows  an  evaluation  of  the  impact  of  changes  in  the 
hardware  configuration,  such  as  faster  drums  or  larger  core 
memory,  as  well  as  the  effect  of  various  mixes  of  user 
demands  on  the  response  of  the  system, 

in  addition,  the  program  was  written  in  such  a  way  th*  .  with 
minor  modifications,  the  simulation  of  the  scheduler  i.r.d 
swapper  could  become  part  of  an  actual  timesharing  a/' tern 
monitor.  Thus  changes  in  the  scheduling  and  swapping 
aljorithmc  can  be  tested  by  simulation  and,  if  they  prove  to 
be  valuable,  incorporated  into  the  actual  system. 

3.  Results 

Throughout  this  section  the  number  of  users  Is  assumed  to  be 
ally  divided  between  TODAS  and  NL5  unless  otherwise  stated, 
giving  the  results  of  the  study,  the  average  anc  the 
60-percent  delay  times  are  used  rather  than  the  maximum. 

l  Standard  ?ar»meter  values  used  for  Simulation 

Hardware  Parameters 

memory  size:  32  pages,  less  7  pages  for  resident  monitor 
and  less  l  page  for  each  NLS  user  (for  display  buffers) 

Drum  laten. yj  17  msec 

Transfer  ratei  17  nsec 

F?le  reference  times  jo  msec 

cpu  see ed s  xcmc. 
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Software  Parameters 

Short  quantumj  l/ii  second 
full  lent  quantum:  l  second. 

User  Parameters 

i  user  types:  NLS ,  TODas,  ana  other 
6a  tasks  for  NLS 
32  tasks  for  TODAS 
1  task  for  OTHER 

Tfte  task  descriptions  for  NLS  and  TQDAS  are  based  on 
studies  of  the  actual  systems. 

b,  User  Types  considereo  in  simulation 

in  the  actual  use  of  the  simulation,  tnree  types  of  users 
were  considered. 

Two  of  the  types  correspond  to  users  of  tne  two 
subsystems  NLS  and  TODAS. 

Users  of  type  NLS  or  TODAS  are  assumed  to  Pe  vorkins 
steadily  and  at  a  relatively  rapid  pace,  cut  their 
work  is  also  assumed  to  be  limited  to  tasks  that  do 
not  require  large  amounts  of  computation  to  complete. 

The  third  type  of  user  is  called  OTHER,  and  is  assumed  to 
working  on  t»sks  that  consist  of  large  amounts  of 
v.  .iputation.  Compilation  is  an  example  of  tnis  kind  of 
tasx. 

one  of  the  main  concerns  tnai  prompted  this  study  was  to 
find  means  to  maintain  fast  response  for  users  of  type 
HLS ,  and  to  a  lesser  degree  those  of  type  TODAS ,  when 
users  of  type  OTHER  are  on  the  system. 

c.  Simulation  of  Current  System 

The  facility  assumea  in  tnis  simulation  has  6lu  of  core 
memory  and  swapping  druns  with  a . s-megabvte  total  capacity. 

Two  views  of  tne  result*  of  tnis  airulation  are  shown  in 
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FIGURE  IV- 1  CURRENT  SYSTEM:  AVERAGE  AND  80-PERCENT  DELAYS 
FOR  NLS  INPUT-FEEDBACK  AND  FILE-REFERENCE  TASKS 
--USERS  EQUALLY  DIVIDED  BETWEEN  NLS  AND  TODAS 
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Fig*.  IV-1  and  iv-2.  For  both  of  these  tne  r.unoer  of  users 
is  assumed  to  oe  eoually  divided  between  types  TOLAS  and 
NLS ,  with  no  users  of  tvpe  OTHER. 

figure  IV-i  shews  ootn  tne  averaee  and  the  aO-percent 
delays  for  NLS  input-feedback  and  file-referencing  tasks, 
in  the  current  syster,  the  data  for  file  referencing 
indicate  the  Kino  cf  delay  experienced  by  a  user  when  he 
asks  the  system  tc  perform  an  editing  function  or  to 
display  a  different  section  of  nis  text.  These  results 
are  very  consistent  with  actual  experience  on  tne  system. 
In  actual  use,  subjective  evaluation  leads  us  to  conclude 
that  the  syster.  becomes  virtually  unusable  when  the 
delays  as  shown  in  this  figure  exceed  about  2  seconds. 

Figure  I v- 2  snows  row  the  tine  distribution  varies  as  the 
number  of  users  increases,  it  i3  interesting  to  note 
here  how  quickly  the  swapping  delays  become  the  major 
factor  in  affecting  response  time  and  new  snail  the 
delays  due  to  confutation  time  are,  section  IV-L-3-f 
below  goes  into  more  detail  on  the  effect  cf  computation 
time. 

d.  Addition  of  the  QKL  iueue 

Tne  simulation  »is  rerun  with  the  addition  of  a  special 
queue  (QNL)  for  interactive  users.  This  queue  has  the 
effect  of  assigning  a  hi^ner  priorty  to  highly  interactive 
functions,  at  the  expense  of  other  tasks.  Figure  jv-3  snows 
the  (approximate)  distributions  of  delay  times  fo"  NLS 
file-refei-er.ee  tasks  vim  and  without  w.HL,  vnen  the  system 
is  serving  3  NLS  user*,  3  TCCAS  users,  and  1  OTHoR  user. 

The  improverent  resulting  from  the  use  of  CNL  is  clear. 

with  respect  to  fig.  Iv-j,  it  is  informative  to  consider 
what  happens  to  the  single  program  of  type  OTHER  in  this 
situation,  it  was  expected  that  the  use  of  onl  would 
result  in  -lowing  the  GTHEk  program;  however,  tne  actual 
effect  was  a  slight  increase  in  its  execution  speed. 

This  is  caused  ry  i  decrease  in  swapping  in  the  syster. 
when  vNL  is  used.  Since  interactive  jobs  are 
reactivated  more  quickly,  there  is  a  greater  cbmcc  .r 
needec  pages  still  being  in  memory,  thus  reducing  the 
swapping.  The  overall  effect  is  an  increase  in  system 
efficiency . 

in  general,  however,  tne  use  of  cnl  may  result  in  a 
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FIGURE  IV-3  SYSTEM  WITH  AND  WITHOUT  QNL:  DISTRIBUTION  OF 
DELAY  TIMES  (IN  SECONDS)  FOR  NLS  FILE-REFERENCE 
TASKS— 3  NLS  USERS,  2  TODAS  USERS,  1  OTHER  USER 
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slowing  of  OTHER  programs.  During  a  given  interval  of 
time,  the  programs  for  OTHER  users  ta*e  up  all  tne  system 
resources  that  are  not  usea  oy  NLS  or  TOLAS  users.  When 
QNL  is  included  in  the  scheduling  aleoritn r,  NLS  ar.a 
TODAS  users  are  able  to  get  better  response  and  thus  they 
work  faster,  taking  up  more  of  tne  system's  resources 
(luring  a  given  interval.  Thus  if  there  is  a  large  number 
of  interactive  tasks,  the  programs  of  type  OTHER  will 
receive  less  tine. 

e.  Drum  Access  and  Bandwidth 

It  is  apparent  Iron  Fig.  IV-2  tnat  tne  major  factors 
affecting  response  time  are  the  delay  encountered  ir, 
swapping  ana,  to  a  lesser  extent,  file  inout/output .  The 
obvious  way  of  improving  this  situation  is  to  provide  a 
device  with  higher  bandwidth  for  swapping  and  file 
input/output. 

in  this  stuay  we  have  not  attempted  to  present  general 
results  relating  response  to  these  factors.  Insteaa,  we 
have  taken  as  a  specific  example  a  Particular  drum  that 
could  replace  tne  present  drums  used  with  the  9«i0  system. 

The  current  drums  have  a  rotation  time  of  34  milliseconds 
and  a  transfer  time  of  about  17  milliseconds  lor  a  2\ 
page  of  24-oit  woras.  The  or ’ms  used  for  comparison  have 
a  rotation  time  of  00  nillis  :onds  and  a  transfer  time 
of  about  5.?  milliseconds  per  age. 

in  addition,  the  new  drums  will  allow  a  page  transfer  to 
begin  at  any  point.  This  means  that  tne  average  time  to 
read  or  write  a  page  will  be  approximately  equal  to  the 
duration  of  a  single  revolution. 

The  effect  of  tne  new  drums  as  predlctea  oy  the  simulation 
is  very  striking. 

A  large  part  of  this  is  due  to  the  consistent  completion  of 
interactive  tasks  witnin  a  snort  Quantum,  with  slower  drums 
these  tasks  often  take  several  short  quanta. 

Figure  iy-u  shows  the  average  and  the  oC-percent  times  for 
NLS  input-f eedback  and  t ile-reierence  tasks  for  a  syster 
veith  QNL,  one  OTHER  user,  and  the  remaining  users  evenly 
divided  between  n'LS  ar.d  TODAS, 

Notice  that  the  difference  between  the  categories  remains 
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FIGURE  1V-4  SYSTEM  WITH  QNL  AND  NEW  DRUMS:  AVERAGE  AND  80-PERCENT 
TIMES  FOR  NLS  INPUT-FEEDBACK  AND  FILE-REFEhENCE  TASKS 
WITH  1  OTHER  USER  AND  REMAINING  USERS  EVENLY  DIVIDED 
BETWEEN  NLS  AND  TODAS 
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relatively  small  and  constant,  This  is  because  both  are 
being  consistently  cor.oletea  vitnin  a  single  activation,  so 
that  tne  difference  in  elaosed  time  is  simply  the  difference 
in  time  required  to  do  the  actual  task. 

As  the  number  of  users  increases,  the  relays  increase 
because  of  longer  aueuea.  Thus  the  limitin g  factor  with  the 
faster  drums  will  be  congestion  ir  the  Queues  and  resulting 
delays  for  input-feedoack  tasks,  rather  than  the  delays  for 
file-reference  tasks,  as  is  tne  case  in  the  current  system, 

f.  speed  of  central  Processor 

in  view  of  the  very  small  percentage  of  time  spent  doing 
computation,  it  is  interesting  to  consider  tne  effect  of 
varying  the  speed  of  the  central  processing  unit  (CPU), 

Figure  IV-5  shows  tne  60-perctnt  time  fer  NLS  file-reference 
tasks  with  tne  current  sy3tem  and  CPU’s  of  various  speeds. 

The  difference  is  small  even  with  a  range  of  U00  to  1  for 
CPU  speeds.  Clearly,  improvement  that  will  benefit  a  syste- 
auch  as  MS  should  be  sought  elsewnere  than  the  CP'J. 

e.  Size  of  Core  Memory 

Although  the  XDS91C  is  limited  to  6aK  of  21-bit  words  for 
core  memory,  it  is  interesting  to  study  tne  effect  of  adding 
more  core. 

Figure  iv-o  3hovs  tne  8C-percent  times  for  NLS 
file-reference  tasks  vith  the  current  system  and  various 
sizes  of  core  memory. 

These  results  should  be  considered  only  as  lower  bounds, 
since  different  scheduling  algorithms  could  be  expected  to 
make  better  use  of  a  larger  memory, 

n.  interactive  Display  Subsystem  (IDS; 

From  the  above  discussion,  it  ic  clear  that  the  greatest 
improvement  in  system  responsiveness  results  frem  the  use  cf 
faster  drums. 

The  limitations  of  the  system  with  rew  drums  are  the 
following » 

(1)  Long  queue  lengths  resulting  in  coor  response  for 
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input-feedback  tasks 

(2)  decreasing  number  of  available  pages  ac  number  of  NLS 
ui era  increase*  (because  of  page*  needed  for  display 
puffers) . 

The  interactive  display  «a&iy,v«K  (IDS)  is  proposed  a*  a 
possible  solution  to  these  imitations,  it  la  made  up  of 
the  following; 

(1)  A  separate  core  memory  for  display  buffers  so  that 
the  number  of  available  paces  remains  constant 

(2)  A  separate  processor  o  perform  input-feedback  tasks. 

A  single  input-feedback  "miniprccessor, "  executing  resident 
code,  should  dc  able  to  service  a  large  number  of  NLS  and 
TCDAS  users.  This  has  the  effect  of  giving  virtually 
instantaneous  response  f  vr  input  feedback,  as  well  as 
reducing  the  load  on  the  main  processor. 

Sine*  input-feedback  tasks  art  by  definition  independent  of 
the  content*  of  the  file  currently  being  referenced,  the 
miniprocessor  needs  only  «  small  description  of  the  current 
command  state  of  the  user.  Feedback  is  the  same  for  all 
users,  so  a  single  program  win  suffice.  This  program  will 
be  resident  in  the  separate  core,  so  swapping  will  not  be 
necessary. 

When  a  user  calls  for  the  execution  of  a  file-reference 
task,  the  mmiprocesoor  passes  identifying  information  to 
the  main  processor. 

This  approach  should  be  applicable  to  any  timesharing  system 
that  is  concerned  with  servicing  a  large  number  cf  users  for 
a  small  number  of  interactive  programs. 

Figure  I V-7  shows  the  80-percent  delay  for  NLS 
file-reference  tasks  in  a  system  with  QNl  and  new  drums, 
with  and  without  IDS.  There  i»  one  OThEH  user;  the 
remaining  users  are  equally  divided  between  NLS  and  TODAS. 

The  minimum  total  elapsed  time  for  a  sin ole  editing 
operation  shows  the  value  of  IDS  more  vividly.  (An 
"operation**  here  means  the  sequence  of  actions  that  an  NLS 
user  gees  through  to  ucnieve  some  desired  effect;  the 
sequence  typically  includes  several  action*  that  require 
input  feefbtek  and  one  tnat  requires  file  reference.) 
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f  GURE  I V-7  SYSTEM  WITH  QNL  AND  NEW  DRUMS.  WITH  AND  WITHOUT 
IDS.  80-PERCENT  TIMES  TOR  NLS  FILE-REFERENCE 
TASKS— 1  OTHER  USER,  REMAINING  USERS  FQUALLY 
DIVIDED  BETWEEN  NLS  AND  TODAS 
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FIGURE  IV-8  SYSTEM  WITH  QNL  AND  NEW  DRUMS,  WITH  AND 
WITHOUT  IDS:  30-PERCENT  TIMES  FOR  SEQUENCE 
OF  3  INPUT-FEEDBACK  TASKS  AND  1  FILE-REFERENCE 
TASK — i  OTHER  USER,  REMAINING  USERS  EQUALLY 
DIVIDED  BETWEEN  MLS  AND  TODAS 
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Figure  I V “ c  sncws  the  total  60-percent  d  **  i  «  y  a  tor  a 
seouence  of  three  mput-feedpac<  tasxs  anti  ore 
iile-rt ference  taax,  in  the  aar.e  system  configurations  as 
shown  in  figure  IV- 7. 

With  IDS,  input-f eedtac <  tasks  nay  oe  assurer*,  to  re 
completes  in  a  quarter  of  a  second  {for  tne  runners  of 
users  considered).  The  curves  of  Figure  iv-e  show  the 
resulting  dramatic  improvement  in  service  to  the  user, 

i *  i^e  On-Line  Systen,  NL5 


1.  Introduction 

HLS,  as  currently  implemented,  is  a  highly  sophisticated 
text-nanioulation  systen  oriented  toward  on-line  use  with 
displays,  its  use  as  an  augmentation  tool  *  a  discussec  ir 
Aoper.dix  A. 

The  program  is  a  subsystem  of  tne  tireshoring  systen  described 
above,  its  size  is  currently  about  thirty  thousand  machine 
instructions,  of  which  about  naif  na<e  up  the  most  frequently 
used  portions.  Tne  jource  languages  used  are  moiyiio  and  a 
collection  of  special-purnose  languages  (SPls)  for  command 
specification,  content  analysis,  and  strinr  manipulation. 

This  section  contains  an  overview  cf  tr.e  creanizatlon  cf  sis,  a 
discussion  of  tne  relationship  of  N Li  to  the  91c-  tmesnarirg 
system,  and  a  brief  discussion  of  possible  future  developments 
ir,  the  program. 

Aobenrtix  D  contains  a  more  detailed  descrioticn  cf  tne  procram 
ana  the  languages, 

2,  overview 

a.  Introduction 

The  following  is  a  conceptual  overview  cf  the  internal 
organization  of  vls,  it  is  conceptual  m  that  the  cverlay 
structure,  forced  upon  Nis  cy  the  United  address  space  ar.d 
fixed  page  size  of  the  910,  does  not  always  correspond  to 
this  description.  Although  efficiency  considerations  have 
entered  into  the  actual  implementation  of  NL5,  the  following 
conceptual  cesenotion  may  3till  oe  used.  It  represents  tne 
design  philosophy  that  guideu  the  implements tion,  and  that 
philosoDhy  was  followed  whenever  practicable. 
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b.  Logical  Organisation  of  MLS 

There  are  three  logical  level*  to  NLS  (see  Fir.  iv-9), 

(1)  The  command  specification  level  Is  trie  highest 
control  level.  It  does  command  recofnltion  and  handle* 
tnt  soecif icaticn  of  actual  operands.  This  1-  the 
interactive  part  of  nls  --  tne  oart  with  which  a  user 
alway*  communicates.  This  level  of  the  system  is  written 
in  the  input-feedback  SPl. 

(2)  The  second  level  of  control  is  the  command  aliorithm 
level.  It  contains  the  algorithm,!  for  performing  the 
various  commands.  Large  parts  of  this  level  of  the 
system  are  written  in  the  content-analysis  and 
string-construction  SPLa. 

(3)  Utility  routines  make  up  the  tnird  and  lowest  level 
of  control.  These  are  the  routines  that  actually  change 
the  data  Dases  perform  I/O,  etc.  Each  of  these  routines 
i*  used  by  several  routines  on  the  second  level  and 
sometimes  by  the  first  level.  The  utility  routines  arc 
the  only  part  of  MLS  that  is  significantly  depenGent  on 
the  hardware,  operating  system,  or  data  structure.  The 
higher  level*  are  all  algorithms  written  with  little  or 
no  consideration  for  the  environment  in  which  tney 
operate.  This  lowest  level  of  the  system  is  written  in 
MOL. 

Command  Specification  Level 

The  command  specification  part  of  NLS  takes  Input  from 
the  user  to  determine  what  command  is  to  be  executed  and 
the  actual  operands  for  the  operation.  It  then  transfers 
control  to  the  appropriate  place  in  the  second  level  to 
execute  the  commano.  Thus,  this  is  the  level  where 
commands  and  actual  operands  are  specified,  but  no  actual 
execution  0*  the  commands  ia  dons. 

The  command  specification  algorithm  or  MLS  is  implemented 
is  a  large  set  of  nested  case  statements.  The  code  gets 
tr.  input  character  and  tests  it  in  a  case  statement, 
which  results  In  some  feedback  to  tne  uper  and  transfer 
of  control  to  the  head  of  another  case  statement  to  test 
the  next  character  of  input. 
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Command  Algorithms 

Tnc  second  level  of  control  consists  of  the  code  that 
implements  the  algorithms  for  tne  various  commands.  This 
level  consists  primarily  of  cilia  on  utility  routines 
that  access  the  data  files,  test  the  data  elements  to 
determine  exactly  wnat  snould  oe  done,  and  call  on  the 
appropriate  utility  routine®  to  perform  tr.e  actions 
required  oy  the  command  Deing  executed. 

The  command  algoritnm  cods  nas  been  organized  into 
several  divisions  based  on  the  commands  tney  effect.  The 
code  for  each  division  of  commands  is  further  divided 
into  a  part  that  includes  the  algorithms  proper  and  a 
part  that  is  more  related  to  (uni  tnus  dependent  on)  the 
logical  data  structure. 

There  a.’e  eight  main  divisions* 

(1)  Structure  Editing 

N’LS  files  have  a  ring  structure.  Each  element  in 
the  ring  represents  a  statement  and  its  associated 
character  string  and/or  line  drawing.  The 
character  string  itself  la  stored  in  a  statement 
data  block  (SDB),  while  the  line  drawing  is  stored 
in  a  vector  data  block  (VD8),  Each  ring  element 
contains  pointers  to  its  associated  SD8  and  VDB  as 
well  as  the  information  that  determines  its 
position  in  the  ring. 

Tncre  if  a  full  set  of  editing  commands  that 
involve  the  manipulation  of  the  ring  structure 
alone  and  do  not  alter  tne  contents  of  the 
statements  (e,g,,  the  "Move  Statement*4  command), 

Tr.e  algorithms  for  these  commands  are  in  this 
section.  They  are  independent  of  data  structure 
and  use  the  structure-manipulation  machinery  to 
actually  effect  changes  in  the  file. 

The  structure  (ring  element)  manipulation  section 
contains  the  algorithm#  ioi  altering  ring  elements 
in  order  to  effect  structure  editing.  They  are 
dependent  on  the  logical  data  structure,  but  r.ot  or. 
the  physical  data  structure  (utility  routine*  are 
used  to  actually  change  the  physical  data). 
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(2)  Text  Editing 

inis  section  contains  tne  algorithms  for  doing 
editing  on  the  text  of  statements,  e.g,,  the 
"insert  word1'  command*  These  algorithms  are 
independent  of  aata  structure.  They  use  the 
content-analysis  machinery  to  aetermine  where 
cnanges  should  take  place,  ana  tne 
string-manipulation  ana  sD^-manipulation  machinery 
to  actually  effect  changes  to  tne  file  (through  tne 
use  of  utility  routines). 

The  content-analysis  section  (usc-a  for  locating 
textual  oatterns  witnm  a  string)  and  the 
string-manipulation  section  are  independent  of 
the  physical  and  logical  structures  of  the  file. 

The  sDy  manipulation  section,  used  for  altering 
SDa  olocxs,  is  not  dependent  on  tne  physical 
data  structure  Put  is  dependent  on  tne  logical 
data  structurct 

(3)  Graphics  Editing 

This  section  contains  the  algorithms  for  commands 
that  edit  line  drawings  (e.c.,  tne  “Insert  Vector" 
command),  and  is  independent  of  the  logical  and 
physical  structures  of  tne  data.  This  code  uses 
Che  \’0b  manipulation  machinery  to  effect  changes  to 
the  file. 

The  VDB  manipulation  section,  used  for  altering 
VDri  blocxe,  is  dependent  -in  noth  tne  logical 
data  structure  and  tne  internal  representation 
of  vectors. 

(a)  Display  Control 

nls  has  an  assortment  of  controls  that  permit  a 
user  to  specify  which  statement  is  to  be  displayed 
at  the  top  of  the  screen  (the  " display-start 
statement")  and  the  selection  processes  to  be  used 
in  determining  vnicn  statements  of  the  file  will 
actually  oe  displayed. 

(a)  Jump  and  linx  machinery 

The  first  function  ic  iemented  in  the  "Jump" 
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The  jump  machinery  if  used  to  select  a 
display-start  statement.  A  ring  of  past 
display-start  statement  identifiers  and 
associated  display  parameters  is  maintained 
to  permit  tne  NL3  user  to  return  to  previous 
views  of  his  file. 

The  link  machinery  is  similar  to  the  jump 
machinery,  except  that  the  new  display-start 
statement  may  he  in  another  file,  in  wnich 
case  a  linx  stack  is  used  instead  of  the  jump 
rim. 

(h)  Sequence  Generator 

once  the  display-start  statement  has  seen 
determined,  the  sequence  generator  is  used  to 
select  abatements  from  the  file  according  to 
currently  invoaea  filtering  criteria. 

The  sequence  generator  uses  tne  display 
parameters,  content  analysis,  and  keyword 
reorganiaat?  on  wrier*  appropriate.  These 
facilities  are  discussed  oelow. 

The  sequence  generator  Degina  at  the 
display-start  statement  and  goes  through  the 
ring  structure  of  the  file,  testing  each 
statement  against  the  filtering  criteria  and 
returning  those  statements  that  pass. 

for  instance,  the  user  may  have  specified 
that  he  wishes  to  see  only  the  first  two 
levels  of  the  ring  structure,  or  only 
those  statements  which  meet  seme  criterion 
specified  by  a  content-analyser  pattern 
(see  oelow) , 

(c)  Diaolay  Parameters 

Display  parameters  controlling  tne  selection 
processes  of  tne  sequence  generator  may  be  set 
at  any  point  in  the  specification  of  a  command. 

The  user  also  has  at  his  disposal  *  set  of 
display-format  control  parameter*  (VIEWspecs) 


for  modifying  hi*  view  of  the  file 


(a)  Content  Analyzer 

A  compiler  is  used  to  generate  code  from  text 
written  in  a  special  high-level  ua*r  language, 
and  this  code  is  used  to  te*t  a  statement  for 
specified  content.  The  content-analysis 
language  available  to  the  user  is  a  sunset  of 
the  content-analysis  mentioned  earlier, 
which  is  used  for  other  content-analysis  code  in 
the  *yst- ;:.n  (e.g.,  for  delimiter  identification 
in  text-editing  command*). 

If  content-analysis  filtering  is  being 
invoked,  the  sequence  generator  uses  the 
compiled  code  to  test  statements  that  have 
passed  all  of  the  other  criteria, 

(e)  Keyword  Reorganisation 

A  list  of  statement  identifiers  is  constructed 
in  response  to  user  selection  and  weighting  of 
Keywords  (named  statements  containing  lists  of 
other  named  statements).  This  list  is  saved 
with  the  file. 

If  Keyword  reordering  is  being  invoked,  the 
sequence  generator  uses  the  list  in 
generating  a  sequence  of  statements, 

it)  create  Display 

The  set  of  routines  called  "cfeate  display-  uses 
the  display-start  statement  identifier,  the 
sequence  generator,  and  the  display  parameters 
to  format  and  construct  a  display  for  the  user, 

(5/  Calculator 

The  calculator  division  is  a  group  of  routine*  that 
effect  arithmetic  manipulations  on  number*  stored 
in  an  NLS  file,  providing  the  user  with  on-line 
numerical  calculation  capability, 

(6?  Processor* 

The  processors  are  not  pr.rt  of  NLS  proper,  but  are 
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activated  py  nls  as  suoprocesses  of  NLS.  They  use 
NLP  machinery  --  primarily  the  sequence  generator 
--  to  provide  input  from  >'ts  files. 

Those  currently  implemented  are  the  MOL 
compiler,  the  SPL  compiler,  tne  Aree  meta 
compiler,  and  tne  outout  Processor,  which 
formate  NLS  files  for  nardccoy  output  to  various 
devices . 

(7)  File  1/0 

Tr.e  file  I/O  division  effects  file  loading  and 
outout . 

(6)  Recovery  and  Initialisation 

Routines  in  this  section  are  executed  when  VLS  is 
started  up  or  continued  after  exiting  to  the 
tire3ruring  executive. 

Utility  Routines 

The  utility-routine  level  of  nls  is  a  collection  of 
subroutines  (written  in  iOL)  that  actually  do  things,  in 
a  sense  the  higher  two  levels  merely  decide  what  tc  do 
and  in  wnat  order.  These  levels  are  essentially 
independent  of  the  macnine,  operating  system,  file 
system,  and  physical  data  structure. 

on  the  utility  level,  data  flies  $.re  changes  and  I/O 
occurs,  some  of  the  utility  rr  . ' nes  are  used  ry  tne  two 
higher  levels  to  read  the  cum  -  jtate  of  the  data 
files.  The  higher  levels  use  tn.j  information  to  decide 
what  to  do. 

This  level  contains  all  routine*  that  actually  read  or 
change  data  fileaf  interact  vitn  the  operating  system,  or 
do  I/O  to  tne  wo rx  stations,  ii  this  manner  all  code 
that  is  dependent  on  tne  environment  (hardware,  software, 
or  Physical  data  structure)  gets  put  in  one  place.  The 
advantages  when  moving  to  a  new  machine  or  when  the 
environment  changes  are  obvious.  Another  consideration 
is  the  nope  that  a  fairly  complete  Horary  of  routines 
will  oe  ouilt  up  and  tne  subsequent  implementation  of  a 
new  command  should  then  oe  quite  easv. 
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3.  Relation  of  NIS  to  the  XDS940  and  the  Timesharing  system  (TSS) 

The  moat  significant  feature*  of  tr.e  XCS940  timesharing  system 
that  affect  NLS  and  are  used  by  it  are  programmed  ODeratcra, 
the  file  system,  paging,  and  forks. 

a.  .programmed  Operators 

Programmed  operators  (called  "pops''')  are  used  extensively  in 
K13  and  tne  compiler*. 

by  means  of  a  POP,  a  subroutine  may  be  called  Just  a*  if 
it  were  a  machine  instruction. 

This  means  that  tne  address  field  of  tne  instruction  may 
oe  used  to  pass  an  argument  to  the  subroutine,  resulting 
in  high'r  code  density. 

in  addition,  for  reentrant  code,  the  transfer  to  a 
subroutine  as  a  POP  can  be  executed  significantly  faster 
than  the  transfer  to  a  normal  subroutine. 

b.  file  system 

It  is  important  that  the  time  required  to  carry  out  an 
operation  on  an  KLS  file  not  increase  greatly  as  the  file 
becomes  larger.  This  requires  the  ability  to  access  random 
segments  of  the  file  with  a  delay  independent  of  the 
location  of  the  segment  in  the  file.  The  TSS  random  file 
system  makes  this  possible. 

Any  block  of  information  in  a  random  file  may  be  referenced 
by  *  system  function  which  is  given  the  file  identif 5.eation, 
an  address  in  tne  file,  an  address  in  memory,  and  the  nusucf 
of  word*  to  be  transferred  as  argument*. 

The  address  space  of  the  file  is  broken  up  into  a  number  of 
blocks  of  fixed  length  (currently  256  words).  Additional 
blocks,  not  in  the  file’s  address  space  (ar.d  hence  available 
only  to  the  system),  are  used  to  record  the  locations  of  the 
file  blocks  ir.  ser, ondary  storage.  The  first  such  index 
block  contains  ad^ resscs  for  the  first  14k  block*  of 
addresses  in  the  file.  If  higher  addresses  are  used  then 
additional  index  blocks  may  te  used, 

c.  Paging  Mechanism 

The  address  space  of  a  program  or.  the  940  can  consist  of  up 


U? 


Sec,  IV 

SOFTWARE  system 


to  eight  pages  of  20L6  words  each.  This  is  not  lar*e  enough 
to  hold  all  of  MS,  and  necessitates  a  rather  complex 
overlay  structure.  Before  this  can  be  explained,  a  oriel' 
discussion  of  the  paging  mecnar.ism  in  TSS  is  needed. 

While  a  program  can  nave  only  eignt  pages  in  its  address 
apace  at  any  one  time,  it  can  have  up  to  63  pages  to  choose 
from.  These  correspond  to  the  63  possible  entries  m  the 
job's  program  memory  table  (PrtT). 

Pages  may  oe  made  availaole  (entered  in  PrtT)  in  two  ways: 

(1)  wnen  a  program  is  first  activated  by  tne  user,  the 
(up  to  a)  pages  maxing  up  tne  program  are  Placed  in  the 
PrtT. 

(2)  Additional  page*  may  be  added  to  the  PMT  oy  the 
program  itself. 

To  ac  this,  it  executes  a  system  function  with  a  file 
name  as  argument.  The  named  file  should  contain  up  to 
eight  additional  page  of  propran. 

Tne  system  enters  tnese  pages  into  the  PrtT  ana  returns 
indices  by  which  the  pages  may  be  referenced.  Such  an 
index  into  tne  PrtT  is  called  tne  "relabeling  byte"  for 
the  page. 

The  relabeling  for  a  program  consists  of  the  exsht 
relabeling  bytes  for  the  pages  currently  making  up  the 
program.  (unused  pages  have  tne  relabeling  oyte  eet  to 
zero. ) 

A  program  may  read  and  set  its  own  relabeling  oy  means  of 
system  functions.  This  allows  the  program  to  bring  Dtges 
from  its  PrtT  into  its  address  space  by  simply  putting  the 
appropriate  relabeling  bytes  into  its  relabeling. 

For  a  more  detailed  discussion  of  these  features  the  reader 
is  referred  to  wef .  13. 

d.  Forks 

The  final  feature  of  tne  TSS  used  by  MS  is  the  ability  to 
create  independent  processes  (called  forks)  within  a  single 
job. 

The  particular  uses  of  forks  in  MS  are  discussed  ir. 
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Future  Development 

The  short-range  extentions  of  NL3  will  include  both 
modifications  of  existing  feature*  and  introduction  of  new 
one®.  The  following  i*  a  partial  list  of  the  poss ibilitie* 
currently  under  consideration. 

The  graphics  capability  will  have  a  wider  variety  of  entities 
and  editing  operations. 

The  calculator  will  allow  several  named  functions  to  be 
maintains!  simultaneously  &nc  will  be  able  to  produce  plots. 

XI  will  be  possible  to  split  the  text  area  into  several 
windows,  allowing  multiple  simultaneous  views  of  a  file,  a 
later  stage  will  allow  different  files  in  the  windows  and 
cross-file  editing. 

Tables  will  be  introduced  as  special  entities  -.onsisting  of 
two-dimensional  arrays  of  strings,  with  column*  either  left  or 
right  justified.  It  will  be  possible  to  display  subsets  of 
rows  and  columns. 

dpeciil  features  will  be  added  to  facilitate  the  use  c£  N is  in 
support  of  on-line  dialogue.  These  include  explicit  structures 
for  bacKlinka  and  comments. 

The  Keyword  system  will  be  replaced  by  a  more  sophisticated 
retrieval  system,  including  automatic  generation  of  inverted 
lists  from  catalogs.  The  user  will  have  languages  to  define, 
store,  and  display  sets  of  catalog  entries, 

A  general  interface  between  WL3  and  processors,  such  as 
compilers,  will  be  developed. 

A  processor  will  be  written  which  will  reconstruct  a  file  in 
such  a  way  that  statements  that  are  structurally  "close'*  will 
also  be  physically  close,  thus  minimising  file  I/O  for  display 
-  instruction. 

It  will  be  possible  to  have  link*  converted  to  page-number 
references  in  hard  copy. 
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l .  The  ARPA  Computer  Network 

1.  History 

Two  prctotyoe  user-program  interlaces  to  the  ARPA  Network  were 
written,  and  were  used  in  primary  communications  between  UCLA 
and  Sdl  and  oetween  SRI  and  the  University  of  Utah.  The  first 
of  these  went  into  operation  in  late  November  1969. 

2.  Current  Status 

The  permanent  Network  operating  system  ia  now  being  finished, 
and  will  oe  operational  i;.  April  1970. 

The  Network  monitor  will  oe  characterised  py  two  different 
Interfaces,  one  to  be  used  oy  persons  operating  on  the  Network 
using  the  aHC  9 UC ,  and  the  ether  to  ce  used  by  programs  running 
on  the  9 UO  and  communicating  with  other  hosts  on  the  Network. 

To  a  person  on  the  Network,  the  9k0  will  iriv^ally  appear 
(with  the  exception  of  certain  procedural  rh&i acteristics ) 
as  it  would  were  he  connected  to  it  via  an  ordinary  Teletype 
linkage. 

Tne  9U0  monitor,  after  dispensing  with  the  procedural 
transmissions  necessary  for  establishing  a  primary  link, 
simply  reads  characters  from  tne  Network  ar.d  r?-aces  them 
into  the  Teletype  incut  buffer  of  an  unattached  9L0 
ctati on. 

in  parallel  with  this  operaticn,  it  transmits  the 
contents  of  that  station's  Teletype  output  buffer  over 
tne  Network, 

The  9k0  user  wishing  to  use  another  host  on  the  Network  must 
dc  so  either  by  writing  a  user  program  which  contains  the 
necessary  monitor  calls  or  by  calling  a  special  Network 
subsystem  (running  on  the  9k0)  which  interfaces  to  the 
monitor  and  makes  the  necessary  calls  for  him. 

Tne  monitor  calls  are  assigned  in  such  a  way  that  the 
programmer  may  consider  the  Network  to  be  an  input/output 
device.  Accordingly,  calls  are  provided  for  the  following 
functions  1 

(1)  OPEN  PRIMARY  LINK 

A  primary  link  ia  established  by  calling  a  system 
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function  with  parameter*  designating  the  desired 
destination  host. 

When  an  attempt  i«  made  tc  open  a  primary  link, 
success  is  indicated  by  a  skip  return  and  a  file 
number  (which  may  be  used  in  successive 
transactions  fjr  identifying  the  link/;  failure  is 
reflected  by  a  non-skip  return  and  an  error  code. 

Assuming  a  successful  return  from  an  OPEN  PRIMARY 
LINK  request,  ine  user  may  immediately  oegin 
transmitting  information  over  the  link,  using  the 
input/output  functions  described  below. 

OPEN  PRIMARY  LINK  is  a  special  system  call  which  is 
unrelated  to  the  other  system  commands  for  opening 
files. 

(2)  CLOSE  PRIMARY  LINK 

CLOSE  PRIMARY  LINK  cause*  the  system  to  disconnect 
a  primary  link  (identified  oy  the  file  number 
obtained  from  OPEN  PRIMARY  LINK)  after  checking  it* 
validity,  a  failure  in  closing  the  link  results  in 
an  illegal-instruction  trap. 

CLOSE  PRIMARY  LINK  i*  a  special  system  call  which 
is  unrelited  to  the  the  other  system  commands  for 
closing  files. 

(3)  INPUT/OUTPUT  TO  PRIMARY  LINK 

input/output  is  handled  in  the  same  way  a*  the 
other  file  l/c  on  the  9LQ. 

The  initial  Network  monitor  will  perform 
single-character  output  over  the  Network. 
Provision  has  been  made  for  multiple-character 
output,  and  it  is  expected  to  be  implemented 
shortly  after  the  initial  network  monitor  is 
operational. 


3.  implementation 

There  are  tv©  basic  tasks  for  vnich  the  network  monitor  nust  be 
responsible*  whe  provision  or  tne  I/O  driver*  necessary  for 
using  the  Network,  and  the  development  of  a  protocol  for 
host-host  communication. 
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Tne  I/O  drivers  have  «uch  functions  as  the  following: 

(i)  Initiation  cf  input./output  commands  tc  the  hardware 
interface 

» 2 )  Detection  of  hardware  interface  errors  and  execution 
of  proper  corrective  or  evasive  actions 

(3)  Suffer  allocation  and  manipulation 

\k)  Correct  formatting  of  messages  so  far  as  the  Imps 
and  the  Network  are  concerned 

(3)  Detection  of  IMP/Network  err crs  and  prober  error 
action 

(6)  Notification  of  910  status  to  the  IMP  and  Network 

(7)  initialization  and  recovery  after  9h0  system  crashes 

(o)  Allocation  ana  maintenance  of  links  over  tne 
Network,  includins  the  handling  of  HFNMs 

19)  Maintenance  of  necessary  internal  tables  pertaining 
to  the  Network 

{ 10 )  communication  between  the  Network  and  ARC  9 UO  work 
stations. 

This  includes  tne  basic  system  calls  required  fer 
input/output,  the  manipulation  of  Teletype  I/O  buffers 
when  a  remote  user  is  connected  to  the  9U0  ah  a 
telephone-l*ne  type  user,  notification  of  work 
stations  about  Network  errors,  notification  of  work 
stations  aoout  illegal  requests,  etc, 

A  protocol  n*s  been  established  vhien  hosts  must  adhere  to 
in  order  to  communicate  effectively. 

The  monitor  must  be  able  to  respond  to  this  protocol  in 
order  to  use  the  Network, 

Although  the  protocol  is  not  yet  in  final  form,  some  of 
the  probAole  areas  of  concern  wij.1  be: 

(1)  opening  and  closing  of  primary  links 

(2)  Opening  and  closing  cf  auxiniary  (f lie-transfer) 
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links 

\3)  Measar*  formatting  (hoet-host) 

( u )  Control  message  decoding  and  interpretation 
(5)  Communication  of  status. 

Since  the  fundamental  Network  drivers  win  be  static  once  they 
are  iffpleEterted,  they  have  been  integrated  into  the  existing 
aonitor  as  efficiently  as  possible. 

The  protocol,  however,  win  probably  oe  subject  to  change  for 
some  tine;  therefore,  it  is  being  implemented  in  a  less 
integrated  but  more  flexible  manner. 

Among  other  things,  it  is  being  coded  in  M0L9A0,  wnich  will 
sake  it  easier  to  debug  and  modify  turn  if  it  were  coded  in 
assembly  language. 

The  general  implementation  approach  is  to  a  large  extent 
dictated  by  the  space  restrictions  in  the  9JiO  monitor. 

We  have  tried  to  put  as  little  code  as  possible  in  the 
rerident  monitor  pages,  and  as  much  as  oossible  in  a 
separate  page  which  may  be  relabeled  in  and  out  of  the 
monitor’ s  relabeling, 

Thus  the  resident  routines  in  the  monitor  are  mainly  the 
ones  that  are  necessary  for  processing  interrupts  and 
certain  communications  (there  ar«  cam es  when  the  Network 
code  mu3t  communicate  with  another  *age  whicn  runs  in  the 
same  position).  The  remainder  of  the  Networx  cede,  and 
buffer  space,  resides  in  the  separate  page. 

Or  The  NLS  UTILTY  subsystem 

Manipulation  of  the  large  number  of  files  which  are  directly  used 
in  connection  with  compiling,  assembling,  loading,  and  debugging 
Nis  is  a  significant  problem.  Accordingly,  a  subsystem  called 
"WL3  UTILTY1*  has  been  written  to  help  handle  these  files. 

MIS  UTILTY  performs  the  functions  described  below  for  the 
synboiic,  binary,  and  core-image  files  of  nls  and  passu  (the 
output  processor) . 
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1.  Archiving 

All  files  relating  to  NLS  ire  permanently  stored  on  the  disc 
under  an  archiving  systen. 

In  order  for  the  files  to  be  accesses,  they  must  be  explicity 
read  from  the  arcnives  to  temporary  storage,  and  any  permanent 
changes  to  a  file  must  be  recorded  by  writing  the  updated 
version  of  the  file  from  temporary  storage  to  archive  storage. 

NLS  UTILTY  nerforms  these  functions  for  tne  user,  as  veil  as 
ensuring  the  integrity  of  files  written  into  archival  storage. 

2.  Compilation 

Subprograms  for  NLS  are  written  in  tnree  different  programming 

languages. 

The  compilation  process  is  different  for  different  languages, 
and  there  is  in  some  instances  an  interaction  between  one 
svmbolic  file  and  another. 

The  concern  tnat  an  NLS  programmer  need  have  with  the  details 
of  NLS  compilation  is  minimized  by  NLS  UTILTY. 

With  NLS  UTILTY,  any  or  all  of  the  NLS  subprograms  may  be 
compiled}  the  compilation  results  are  reported  to  tne  user  in  a 
manner  which  he  designates. 

3o  Loading 

The  loading  process  for  NLS  is  scmewnat  complex. 

The  unloaded  NLS  system  consists  of  more  than  bO  Dinary  files, 
and  they  must  oe  loaded  in  a  certain  order  and  in  a  certain 
relationship  to  each  other. 

As  in  compilation,  NLS  UTILTY  makes  it  unnecessary  for  the  MLS 
programmer  to  concern  nimself  with  the  peculiarities  of 
loading. 

The  loaded  system  consists  of  7  core-image  files. 

While  the  file*  are  closely  related,  there  is  frequently  value 
in  loading  only  one  or  another  of  them. 

For  this  reason,  NLS  UTILTY  allows  a  variety  of  loading 
options,  including  one  whitn  loads  the  entire  system,  and  one 
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which  loads  4  specific  file, 
ii  *  Listing 

because  of  the  size  of  nls,  the  maintenance  of  up-to-date 
listing*  is  a  tedious  job. 

Function*  provided  in  NLS  enable  the  programmer  to  produce  any 
number  of  listings  of  4ny  or  all  NLS  symbolic  files  by  a  simple 
procea*. 

More  details  on  the  individual  functions  and  the  operation  of  mis 
UT1LTY  may  be  found  m  Appendix  D. 
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A.  General 

Future  directions  sor  work  in  the  ARC  will  be  influenced  by  forces 
originating  both  inside  ar.d  outside  vOe  center. 

Forces  generated  by  our  cumulative  experience  in  the 
development  of  augmentation  systems  within  the  center  indicate 
some  new  directions  for  our  own  bootstrapped  research  effort* 

External  forces  are  generated  by  our  participation  in  the  tRPA 
Network  experiment  and  by  an  increased  awareness  for  the  noed 
to  communicate  with  the  "outside  world"  --  people  outside  the 
Center  who  are  engaged  in  reiatso  work. 

The  internal  forces  and  those  generated  by  our  Network 
participation  combine  to  produce  a  shift  in  our  internal  research 
emphasic  towards  two  specific  activities:  (l)  team  augmentation 
and  (2)  the  development  of  a  system  design  discipline.  These  are 
discussed  below  under  "Shift*  in  Emphasis." 

Increased  awareness  of  the  rue d  to  communicate  and  interact  with 
the  outside  world  will  lead  toward  the  development  of  a  new  are* 
of  specific  concern,  discussed  below  under  "Transfer  of  Results," 

The  goals  associated  with  research  in  team  augmentation,  with  the 
development  of  a  system  design  discipline,  and  with  the  transfer 
of  result*  are  related  to  one  another  within  trie  ARC  goal 
structure  as  described  below  in  the  section  entitled  ’'Short-Term 
and  Long-Term  Goals," 

in  the  section  "selected  Plans  under  other  sponsorship,"  we 
discuss  the  System  Developer  interface  activity  ( SYDIA) ,  for  which 
we  are  seeking  additional  sponsorship,  it  is  intended  that  this 
activity  will  be  the  primary  effort  in  the  area  of  the  transfer  of 
results , 

8.  Shift*  in  Emphasis 

Our  Plans  reflect  a  maturing  shift  in  emphasis  in  our  research 
work.  We  plan  to  shift  our  emphasis  toward  twe  baiic  activities: 
(1)  team  augmentation  and  (2)  the  development  of  a  system  design 
discipline. 


Preceding  page  blank 
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i.  T6U.  AU*v.ent5.tion 


Whereas  In  the  past  we  have  yiven  moat  of  our  attention  to 
augmenting  the  individual  worker,  we  are  now  focus-ink  on  the 
augmentation  of  &  team  of  collaborating  workers,  each  of  wnom. 

Is  individu  ly  augmented. 

The  high  mobility  and  manipulative  capaDility  of  a  skilled 
"augmented  individual"  has  a  ur^que  potential  wnicn  can  be 
realized  \h*n  a  number  of  augmented  individuals  Com  ±nto  a 
collaborative  team.  Not  only  can  each  individual  move  very 
rapidly  through  the  Joint  working  files  to  study  them,  enter 
new  information,  and  upo&te  old  material,  bLt  this  nower  can  oe 
amplified  by  special  computer  aids,  conventions,  and  skills 
tr..:  v  directly  facilita?**  the  processes  of  intercommunication 
t-iU  coordir.ati.or.. 

The  contemplA'.cd  efforts  in  "team  augmentation"  involve 
several  facetsi 

(1)  The  development  ;  I  conventions  and  procedures  for 
organising  the  working  records  of  our  plans,  sealers. 
Objectives,  design  principles,  schedules,  etc.,  so  as  to 
give  effective  mutual  "task  orientation"  to  tht  members 
of  a  team  by  ensuring  optimal  accessibility  of  ail 
information  related  to  the  team1#  objective. 

(2)  The  special  development  of  a  "Dialogue  Support 
System"  to  facilitate  the  lapia  evolution  of  these 
working  records  via  dialogue  among  members  of  the  design 
team. 

(3)  The  development  of  techniques  to  facilitate 
simultaneous  remote  collaboration  among  people  at 
physically  remote  on-line  terminals  (of  any  sort),  by 
giving  them  direct  communication  with  one  another, 
independent  of  their  current  individual  work  interactions 
with  the  computer.  This  include*  provision,  where 
feasible,  for  the  following! 

(a)  video  and/or  voice  intercommunication 

(b)  Easy  and  flexible  control  of  means  for 
duplicating,  at  any  terminal,  all  or  part  of  the 
type-out  or  display  from  another  terminal 

let  r.eady  transfer  of  control  of  one  terminal's 
computer  interaction  to  another  terminal's  input 
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device*. 

These  techniques  will  evolve  within  ARC  under  conditions  of 
application  to  our  own  coordinates  system-development  work, 
and  will  be  applied  over  a  wide  ranee  of  collaborative 
actions,  from  simple  question-answering  facilities  tc 
complex  design  work  involving  intense  mutual  particioation 
by  the  team  members. 

as  applicable  techniques  become  effective  within  ARC,  we 
will  explore  their  use  and  value  for  the  following i 

u\)  Support  of  Network  Information  center  (NIC)  services 
such  as  teaching,  question-answering,  and  some  types  of 
query  servicing 

(2)  working  collaboration  between  ARC  staff  and  personnel 
at  other  Network  sites 

(3)  working  collaboration  between  people  at  remote 
Network  sites,  independent  of  ARC  staff. 

2.  Development  of  User-  ar.d  service-system  Design  Discipline 

The  functional  features  of  the  ’‘user  system*  --  the  large 
collection  of  computer  aids  available  to  an  ARC  worker  -•  have 
evolved  with  some  ingenuity,  a  sreal  deal  of  eut-end-try 
experimentation  under  actual-u^age  conditions,  and  a  certain 
specie.!  orientation  offered  by  our  overall  research  framework. 
However,  up  to  now  there  ha*  been  a  significant  lack  of 
objective,  methodical  engineering  design  for  the  overall  user 
system, 

A  user-system  design  discipline  if  definitely  needed,  and  we 
intend  to  devote  an  increasing  amount  of  effort  toward 
developing  such  a  discipline. 

like  the  user  system,  the  "service  system”  -•  the  hardware  and 
software  underlying  the  features  for  augmenting  users  --  has 
evolved  in  an  ad  hoc  fashion. 

Here  there  is  also  a  significant  need  for  a  system-design 
discipline, 

A  system-design  discipline  wculd  have  a  communicable, 
teachable,  generally  applicable  framework  supporting  a 
coordinated  set  of  concepts,  terminologies,  principles, 
methods,  and  special  tools. 
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C.  transfer  of  Result* 

Behind  these  basic  aspects  of  our  work  m  the  ARC  {team 
augmentation  ana  design  disciplines)  lies  an  essential  feature  of 
our  long-tern  strategy#  namely,  the  goal  cf  producing  results  that 
will  be  of  direct  value  to  other  group*  of  system  developers  --  in 
Particular#  to  those  who  will  be  developing  augmentation  systems. 

This  i*  in  contrast  to  being  of  direct  value  to  customers  who 
will  want  systems  for  their  own  direct  use  {e*g.,  to  augment  a 
manager,  a  designer,  an  editor,  or  a  researcher). 

Display  terminals#  communication  channels,  and  computer  service 
are  destined  to  become  both  cheap  ana  plentiful,  and  it  is  certain 
that  a  very  large  number  of  organizations  win  want  to  use  them. 
They  must  rely  upon  system  developers  vno  will  need  to  be  capable 
of  the  following: 

(1)  Analysis  of  system-ueage  environments 

(2)  Desig.;  and  implementation  of  a  smooth,  powerful,  and 
coordinated  system  of  user  aids,  conventions,  methods,  etc. 

(3)  Training  and  "education"  of  new  users,  many  of  whom  will  be 
completely  unfamiliar  with  the  potential  of  this  new  technology 

(L)  subsequent  monitoring  of  user  performance  so  as  to 
implement  the  chan/es  necessary  to  track  the  evolution  of 
users*  attitudes,  concepts,  sxills,  usage  habits,  and  wantSj 

Although  it  is  important  to  stimulate  the  eventual  customers  for 
augmentation  systems,  and  to  make  them  aware  of  the  potential  for 
these  systems  in  their  work,  we  feel  that  our  results  should  be 
directed  primarily  toward  helping  system  developers,  over  the 
longer  term,  we  plan  to  do  this  sy  pursuing  the  following  goals: 

Item  lj  Making  visible  an  auvanced,  integrated  system, 
operating  in  a  heavy-usage  environment,  that  can  orient  system 
developers  to  the  available  cost-value  tradeoffs 

Item  2 1  Developing  in  effective  system-de sign  discipline  to 
bid  in  developing  augmentation  systems,  whether  or  not  these 
system*  resemble  ours 

Item  3 i  Maintaining  thorough,  highly  current,  comprehensive 
documentation,  designed  for  quick  location  of  relevant  raterial 

Item  u:  I  -t&blianing  broad-oand  communication  channels  over 
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which  a  dynamic  ii.terchange  of  information  c*n  take  place,  so 
that  a  maximum  proportion  of  oar  knowledge  can  be  quickly 
available  in  useful  form 

item  51  offering,  aa  a  model,  a  complete  prototype  ceaign  of 
an  augmentation  ayatem  especially  designed  for  augmenting 
system  development. 

This  ayatem  would  be  compatible  with  the  system-design 
disciplines  described  above,  and  would  include  techniques 
for  planning,  analyzing,  designing,  programming,  debugging, 
documenting,  and  teaching. 

D.  Short-Term  and  Long-Tarm  Goals 

Our  approach  to  the  planned  work  will  be  as  fellowai 

(1)  Achieve  the  short-term  goals  implicit  in  the  team 
augmentation  activity,  in  the  development  of  a  system  design 
discipline,  and  in  the  tasks  Itemized  under  Transfer  of  Results 
(Section  V«c  above) 

(2)  contribute  to  the  long-term  goal  of  directing  our  results 
for  maximum  benefit  to  future  developers  of  augmentation 
systems. 

There  is  considerable  overlap  between  short-term  and  long-term 

goals. 

For  instance,  in  the  case  of  the  transfer  of  results,  the  basic 
bootstrapping  development  of  techniques  within  the  ARC  seems  to 
guarantee  a  very  good  basic  buildup  toward  items  l,  2,  2,  and  5 
of  Section  V-C;  our  participation  in  the  Network  experiment 
contributes  directly  to  item  >ij  and  the  development  of  the  NIC 
service  will  contribute  toward  Items  1  and  li. 

E.  selected  Plans  Under  other  Sponsorship 

To  pursue  directly  the  itemized  long-range  goals  of  section  V*C, 
we  currently  have  other  plans  under  consideration,  coordinated 
with  those  outlined  in  this  proposal.  These  plans  would  be 
carried  out  under  other  sponsorship* 

ve  are  formulating  plans  for  what  we  tentatively  call  the 
System  Developer  Interface  Activity  (SYDXA).  rfe  expect  to  oe 
approaching  representative  candidate#  during  1970  with 
proposals  for  multiple  sponsorship.  The  initial  purpose  of  the 
3YDIA  will  be  to  develop  the  followings 
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skills  erJinLf?*  ef*ecUve  intercntme  of  information, 
°pl-entAtion,  etc.  between  ARC  and  the  existinc  and 
potential  community  of  augmentation-system  developers 

(2)  The  ability  to  aasist  other  froupa  to  transfer  our 

or  P4rt«  of  It.  directly  into  another  hardware 
envir  onment , 

specific  inaividutl  funding  .rrinfewnli,  we  would 
.n,Sf*lnwa*V?l0Fin*  cl5*e  ^erchange  relition.nlps  wi-.n 
tSri  elCpnent  troup*!  hopefully,  some  group,  would 

then  adopt  our  augmented  tecj.niquei  for  .y.tem-aevelocnent 

W  O  i  K  • 
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ARC*  Acronym  for  the  Augmentation  Research  canter  at  Stanford 
R eiesr'.h  Institute, 

ARPAi  Acronym  for  the  Advanced  Research  Projects  Agency. 

Alimentation  *  ueed  in  this  report  to  indicate  the  extension  of  human 
intellectual  and  organixational  capabilities  by  means  of  close 
Interaction  with  computer  aids  and  by  use  of  special  procedural  and 
organisational  techniques  destined  to  support  and  exploit  this 
interaction. 

Center*  Another  term  u#eu  for  the  ARC. 

Console*  as  used  here,  this  means  specifically  a  uaer^  control 
console  for  the  ARC1*  On-Line  System  OILS).  The  consoles  presently 
in  use  consist  of  a  display  screen,  a  keyboard,  a  "mouse",  and  a 
"keyset. " 

Files  As  used  here,  this  refers  to  a  unified  collection  of 
information  held  in  computer  storage  for  use  with  the  On-Line  System 
(HIS)  or  with  TOLAS.  A  file  may  contain  text  (natural  language  or 
program  code),  numerical  information,  graphics,  or  any  combination  of 
these.  Conceptually,  a  file  corresponds  roughly  to  a  hard-eopy 
document, 

GLHIES  Project  QIHI.E,  at  the  University  of  California  at  Berkeley, 
develooed  (under  ARPA  sponsorship)  the  timesharing  software  for  the 
XDS9L0  computer  used  by  the  ARC. 

OODOsa  Acronym  for  Graphicc-Oriented  Document  output  system,  l  means 
for  converting  KLS/TODAS  files  to  microfilm.  GQDOS  is  capable  of 
handling  the  line  drawings  produced  with  the  NLS  graphics  capability, 

IMP*  Acronym  for  interface  Message  processor,  a  component  used  in  t*..e 
aSPA  Network. 

Keyset*  A  device  consisting  of  five  keys  to  be  struck  with  the  left 
hand  in  operating  the  On-line  System  (NLS), 

MOL*  See  M0L9a0« 

M019L0*  A  machine-oriented  language  for  the  XDS9kO  computer.  MOi9ko 
(or  simply  MOL)  was  developed  at  ARC. 

Mouse*  A  device  ©oersted  by  the  right  hand  in  using  the  On-Line 
System  (NLS).  The  mouse  rolls  freely  on  any  flat  surface,  causing  a 
cursor  spot  on  the  display  screen  to  move  correspondingly. 

NASA?  National  Aeronautics  and  Space  Administration, 
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Network*  The  planned  Advanced  nesearch  projects  Agency  network  of 
research  computer  installations, 

NIC:  The  Network  Information  Center,  to  be  incorporated  in  tne  aRPA 
network.  The  NIC  will  operate  as  a  computer-assisted  library  servic 
for  information  pertaining  to  the  network,  to  be  Msei  oy  network 
members,  and  will  be  operated  py  ARC. 

NLSt  See  On-Line  System. 

On-Line  System  ! NLS ) s  Tnis  is  the  ARC'S  principal  and  central 
development  in  tne  area  of  computer  aids  to  the  human  intellect.  As 
presently  constituted,  it  is  a  display-oriented,  timeshared, 
wuiticonsole  system  for  the  cor.Dosition,  study,  and  modification  of 
files  (see  definition  of  "file"),  A  counterpart  system,  TOGAS , 
operates  from  hard-copy  terminals  such  as  Teletypes  and  offers  many 
of  the  same  capabilities  as  NLS. 

PASS  a i  An  output-Droceswing  program  used  to  convert  NLS/TODAS  files 
tc  hard-copy  format  for  output  via  one  of  a  number  of  different 
devices. 

KADC:  Acronym  for  Rome  Air  Development  Center. 

SPL i  Acronym  for  Special-Purpose  Language.  Specifically,  this  tern 
ia  used  for  the  SPL'*  developed  at  ARC  for  use  in  programming  NLS. 

SRI*  Acronym  for  Stanford  Research  institute 

Statement*  The  basic  structural  unit  of  an  NLS/TODAS  file,  a 
otatement  consists  of  an  arbitrary  string  of  text,  plus  graphic 
information.  A  file  consist*  of  a  number  of  atatenente  in  an 
explicit  hierarchical  structure. 

TODAS*  Acronym  for  the  Typewriter-oriented  Documentation-Aid  System. 
TODAS  is  a  counterpart  of  NLS  designed  to  operate  from  hard-copy 
terminal*  such  as  Teletypes. 

Tree  Meta*  A  compiler-compiler  system  developed  at  ARC, 

TSS*  Acronym  for  'me-sharing  system,  specifically,  the  system 
developed  by  Project  GENIE  for  the  XDS9LO  computer. 

XD89kO*  The  computer  facility  used  by  AkC  is  cased  upon  a  Xerox  Data 
3y*tems  (formerly  Scientific  Dc,ta  ayttems  or  SDS)  model  9L0 
timsharing  computer. 


9a0:  See  XD39LC 
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I  The  On-Line  System  0T,3) 

A.  Introduction 

NLS,  as  currently  implemented,  is  essentially  a  hignly 
sophisticated  text-manipulation  system  oriented  primarily 
toward  on-line  use;  i.e.(,  it  is  not  primarily  oriented  toward 
production  of  hard  copy,  although  fairly  sophisticated 
hard-copy  formatting  and  output  are  included  in  the  system. 

NLS  is  intended  to  be  used  on  a  regular,  more  or  lees  full-time 
basis  in  a  timesharing  environment,  by  userw  vno  are  not 
necessarily  computer  professionals.  Th*  users  are,  however, 
assumed  to  be  "trained"  as  nppoMd  to  "naive,"  Tnus  tne  system 
is  not  designed  for  extreme  simplicity,  nor  for 
•elf-explanatoi y  features,  nor  for  compatibility  with  "normal" 
working  procedures. 

Rather,  it  is  assumed  that  the  user  has  scent  considerate 
time  in  learning  the  operation  of  the  system;  that  he  uses 
it  for  a  major  portion  of  his  work;  ana  that  he  is 
consequently  wixiin?  to  adapt  his  working  procedures  to 
exploit  the  possibilities  of  full-time,  interactive  computer 
assistance, 

Thu*  the  practices  and  techniques  developed  by  users  for 
exploiting  NLS  are  as  much  a  subject  of  research  interest  as 
the  development  of  NLS  itself. 

Section  :v  of  this  appendix  is  a  glossary  of  special  NLS/TODAS 
terminology. 

B.  work-station  console 

The  user  sits  at  a  console  whoee  main  elements  are  a  displav 
screen,  a  typewriter  keyboard,  a  cursor  device  called  the 
"mouse,"  and  a  set  of  five  Keys  operated  by  the  left  hand, 
called  the  "Keyset," 

The  screen  is  used  for  displaying  text,  in  various  formats. 
The  top  portion  of  the  screen  (approximately  1/5  of  the 
total  area)  is  reserved  for  feedback  information  of  various 
kinas:  the  name  of  the  user  command  mode  currentl'-  in 
effect,  a  "register"  trea  used  for  various  kinds  of 
feedback,  an  "echo  register"  which  displays  the  last  six 
characters  typed  Dy  the  user,  and  other  items  which  are 
explained  below. 

The  keyboard  closely  resembles  a  conventional  typewriter 
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keyboard,  with  a  few  extr*  Keys  for  special  character*  and 
control  functions.  It  is  ujcq  for  typing  text  as  content 
lor  a  file  and  for  specifying  commands,  wni.cn  are  given  as 
two-  or  trtree-cnarac ter  mnemonics. 

The  nouse  is  r  roughly  box-shaped  object,  about  four  incnes 
on  it#  longest  side,  vnich  is  moved  oy  the  rignt  nand.  It 
is  mounted  on  vneela,  and  rolls  on  any  flat  surface.  The 
wheels  drive  potentiometers  wnicn  are  read  by  an  A/D 
converter,  and  the  system  causes  a  trucking  spot  (''cur"}  to 
move  on  the  screen  in  correspondence  to  the  notion  of  the 
mouse, 

Tne  user  specifies  locations  in  the  displayed  text  ty 
pointing  with  the  nouse/bug  combination.  This  eliminates 
the  need  for  upeeifying  a  location  by  entering  a  code  of 
come  kind,  Use  of  the  mouse  is  very  easily  learned  and 
soon  becomes  unconscious, 

on  top  of  tne  mouse  a ~e  three  special  control  buttons, 
whose  uses  are  described  oelcv. 

The  Keyset  has  one  key  for  each  finger  of  the  left  nand. 

Ine  Keys  are  strucK  in  combinations  called  "chords,"  and 
each  chor'i  corresponds  to  a  charmter  or  combination  of 
characters  from,  tne  keyboard.  There  are  31  possible  chords; 
beyond  this,  two  of  tne  buttons  on  the  mouse  may  be  used  to 
control  the  "case"  of  the  Keyset,  jiving  alternative 
meanings  to  e&cn  chora.  xnere  are  four  oossible  cases,  for 
a  total  of  12)1.  possible  combinations. 

A  simple  binary  code  is  used,  and  has  proved  remarkably 
easy  to  learn.  Two  or  three  hours’  oractice  are  usually 
sufficient  to  learn  the  most  commonly  used  chords  and 
develop  reasonable  speed. 

The  Keyset  w^s  developed  to  increase  the  user's  speed  and 
smoothness  in  operating  NLS,  it  was  founu  that  users 
normally  Keep  the  right  hand  on  the  mouse,  because  the 
great  majority  of  command  operations  involve  a  pointing 
action?  efficient  use  of  the  Keyboard,  hoover,  reauires 
the  use  of  both  hands,  and  shifting  the  rirnt  nand  (ard 
the  user's  attention)  to  the  Keyboard  is  distracting  and 
annoying  if  it  must  be  done  for  each  two-  or  three-letter 
command  mnemonic* 

Use  of  the  keyset  permits  the  user  to  Keep  Ms  right 
hand  on  the  mouse  and  his  ltft  on  the  Keyset, 
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reverting  tc  the  keyboard  only  f or  entry  of  long 
strings  of  text  (typically  five  or  more  cl.  actera). 

Originally,  the  keyset  exactly  duplicated  the  keyboard  in 
function;  in  the  development  of  NLS,  however,  certain 
control  functier.a  have  been  made  two-stroke  operations 
from  the  Keyset  where  they  would  oe  three*  or  four-stroke 
operation*  from  the  keyboard.  Nevertheless,  it  is  still 
possible  to  operate  all  of  the  features  of  NLS  without 
using  the  keyset;  thus  the  beginner  may  defer  learning 
the  keyset  code  until  ne  has  gained  some  degree  of 
mastery  over  the  rest  of  the  system. 

C.  structured  Text 

"Text"  is  used  here  as  a  very  general  term,  A  ”iileH  of  text 
(corresponding  roughly  to  a  ’’document"  in  hard  copy)  May 
consist  of  English  or  some  other  natural  language,  numerical 
data,  coaputer-prograra  statements,  or  anything  else  that  can  be 
expressed  as  a  structure  of  character  string*.  Simple  line 
drawings  can  also  be  included  in  a  file. 

All  text  handled  by  NLS  is  in  "structured-statement"  form. 

This  special  format  is  simply  a  hierarchical  arrangement  of 
"statements, *  resembling  a  conventional  "outline11  form. 

Each  statement  in  a  file  may  ce  considered  to  possess  1 
"  tatement  number,"  which  shows  its  position  ana  level  in 
tne  structure.  Thus  the  first  statement  in  a  file  is 
Statement  l;  its  first  substatement  is  1a,  and  its  next 
•ubstatement  is  IB;  the  next  statement  at  the  same  level  as 
the  first  is  Statement  2;  and  so  forth.  Statement  number* 
have  been  suppressed  in  printing  out  most  of  this  document, 
but  are  printed  out  for  the  remainder  of  this  section  as  an 
example. 

Ia3bla  Every  statement  also  bears  a  “signature"  which 
may  be  displayed  on  command.  The  signature  is  a  line  of 
text  giving  the  initial*  of  the  user  who  created  the 
statement  (or  modified  it  most  recently)  and  the  time  and 
date  when  this  was  done, 

Ia3b2  A  statement  is  simply  a  string  of  text,  of  any 
length;  this  serves  as  the  basic  unit  in  the  construction  of 
the  hierarchy,  in  English  text,  statements  are  normally 
equivalent  to  paragraphs,  section  and  subsection  headings, 
or  items  in  a  list,  in  other  types  of  text,  statements  may 
be  data  Ate;:.'?,  program  statements,  etc. 
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Ia3b2a  Each  paragraph  ana  heading  in  this  document  Is  an 
NLS  statement,  Each  statement  la  indented  according  tc 
its  "level"  in  the  hierarchy;  this  paragraph  is  \ 
substatement  of  the  one  aocve,  which  is  in  turn  a 
flUbstatement  cf  another  statement,  a  statement  nay  have 
any  number  of  suostateraenta,  ana  tne  overall  structure 
may  have  any  number  of  levels. 

Ia3c  Note  that  wnen  a  user  creates  a  file,  ne  nay  let  all  of 
his  statements  oe  first-level  ones,  i.e.,  1,  2,  3,  etc.  In 
this  case  he  will  not  have  to  consider  a  nierarcnicaJ  structure 
but  simply  a  linear  list,  as  is  founc  in  conventional  text. 

l&3cl  However,  nany  of  tne  features  oi  ‘«LS  are  onentea  to 
maxe  use  of  hierarchy,  ana  the  benefits  of  these  features 
are  lost  if  hierarchy  is  not  exploited. 

Ia3c*  This  is  an  exawcls  cf  an  NLS  feature  to  wnicfc  the 
user  must  accomodate  his  methods;  however,  tne  experience  of 
users  has  been  that  hierarchical  structure  very  rapidly 
becomes  a  completely  "natural"  way  cf  organizing  text,  Many 
automatic  features  of  NLS  m*xe  the  structure  easy  to  use: 
for  example,  statement  numbers  are  created  automatically  at 
all  times  ana  tne  u?*r  need  not  even  be  aware  of  them,  it 
is  sufficient,  when  the  user  creates  a  statement,  to  specify 
it?  level  relative  to  the  preceding  statement. 

D-  Use  of  the  System 

Text  manipulation  is  considered  tc  involve  three  basic  types  of 
activity  by  the  user:  composition,  study,  and  modification.  In 
practice,  tne  three  activities  are  so  intermingled  to  oe 
indistinguishable. 

1.  composition 

composition  is  simply  the  creation  of  new  text  material  as 
content  for  a  file. 

in  tne  simplest  case,  the  user  gives  the  command  "insert 
Statement"  by  tycing  "is".  He  then  coints  (with  tne  mouse) 
to  an  existing  statement;  tr.e  system  displays  a  new 
statement  number  which  is  the  logical  successor,  at  the  sane 
level,  as  the  statement  pointed  to.  Tne  user  may  cnange  the 
level  of  this  number  upward  oy  typing  a  "u"  or  downward  by 
typing  i  *d”. 

NOTE:  Even  if  no  previous  statement  has  ceen  created. 
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the  system  displays  a  "dummy"  statement  at  the  top  cf  the 
text-display  area,  and  tne  user  points  to  this  dum*y. 

The  user  then  types  the  text  of  the  new  statement  from  the 
Keyboard.  On  the  screen,  the  top  part  of  the  text-display 
area  is  cleared  and  characters  are  displayed  hers  as  they 
are  typed.  When  the  statement  is  finished,  the  user  hits  a 
CA  {command  accept)  button  on  the  Keyboard  or  mouse,  and  tne 
system  recreates  the  display  with  the  new  statement 
follovin*  the  one  that  was  pointed  to. 

Hew  material  may  also  be  added  to  existlr.c  statements  by 
means  cf  commands  such  as  insert  word,  insert  Text,  and 
others,  properly  speaKinf,  these  operations  are 
modification  rather  than  composition,  and  are  discussed 
below. 

Simple  lino  drawing*  may  be  compoaed  and  added  to  the  file 
by  means  of  the  "vector  package.”  This  is  diicussed  in 
another  section  of  this  report, 

2.  Study 

The  study  capabilities  of  NLS  constitute  its  most  powerful 
and  unusual  features.  The  following  it  only  a  brief, 
condensed  description  of  the  operations  that  are  possible. 

a.  Jumping 

NLS  files  may,  of  course,  contain  a  great  deal  more  text 
than  can  be  displayed  on  the  screen,  just  as  a  document 
may  contain  more  than  one  page  of  text.  An  NLS  file  is 
thought  of  as  a  long  "scroll."  The  process  of  moving 
from  one  point  in  the  scroll  to  another,  which 
corresponds  to  turning  pages  in  hard  copy,  is  called 
"jumping."  There  is  a  very  large  family  of  jump 
commands. 

The  oasic  jump  command  is  jump  to  Item.  The  user 
specifies  it  by  entering  "ji",  and  then  points  to  some 
statement  with  the  mouse.  The  eeleeted  statement  is 
moved  to  the  top  of  the  screen,  as  if  the  scroll  had 
been  rolled  forward. 

nost  of  the  jump  commands  reference  the  hierarchical 
structure  of  the  text.  Thus  Jump  to  Successor  brims 
to  the  top  of  the  display  the  next  statement  at  the 
same  level  as  tne  selected  statement;  Jump  to 
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Predecessor  doe*  ^he  reverse;  Jump  to  Ud  starts  the 
display  with  the  statement  of  whicn  the  selected 
statement  is  a  substatemeni,  and  so  forth. 

The  jump  to  Name  command  uses  a  different  wav  of 
addressing  statements.  If  tne  first  word  of  any 
statement  is  enclosed  m  parentheses,  tne  system  win 
recognize  it  as  the  MnameM  of  the  statement.  Then,  if 
this  wora  appears  somewhere  else  in  the  text,  the  user 
may  Jump  to  the  namea  statement  by  pointing  to  the 
occurrence  of  the  name,  or  py  typing  the  name. 

This  provides  a  cross-referencing  capability  whicn 
is  very  smooth  and  flexible;  the  command  Jump  to 
Return  will  always  restore  the  previous  display,  so 
tha  the  user  may  follow  name  references  without 
losing  his  place. 

It  is  also  possible  to  Jump  to  a  statement  by  typing 
its  statement  numper. 

b.  View  Control 

If  a  file  is  long,  it  nay  b?  impossiole  for  the  user  to 
orient  himseli  tc  its  content  and  structure  or  to  find 
specific  sections  by  Jumping  through  it.  ine  principal 
solution  to  tMs  problem  is  provided  by  level  control  and 
line  truncatioi  . 

Level  control  permits  tne  user  to  specify  some  number  of 
levels;  tne  system  will  then  display  only  statements  of 
the  specified  level  or  higher.  Thus  if  tnree  levels  are 
specified,  only  first-,  second-,  and  tnird-levei 
statements  are  displayed. 

Line  truncation  permits  specification  of  how  many  lines 
of  each  statement  are  to  be  displayed.  Thus  if  one  line 
is  specified,  only  the  firat  line  of  each  statement  will 
be  displayed. 

Common  usage  is  to  use  the  first  two  or  three  levels  in  a 
file  as  headings  describing  the  material  contained  under 
each  heading  ir.  the  form  cf  eubstatene^ts .  Thus  the  user 
may  start  oy  looxing  at  a  display  showing  only  tne 
first«level  statements  in  the  file,  one  line  of  each. 

This  amounts  to  a  table  of  contents. 

Ke  may  then  select  one  of  these  statements  and  jump  to 


lU 


Appendix  A 

NLS/TODAS  USER  FEATURES 


it,  specifying  one  more  level.  He  will  then  see  more 
details  of  the  content  of  that  part  of  the  file.  This 
process  of  "exoanding  the  view"  may  be  reseated  until 
the  user  has  found  what  ne  is  looking  for,  at  which 
point  ne  may  specify  a  full  display  of  the  text. 

User*  r?oon  develop  a  habit  of  structuring  file*'  in 
such  a  way  that  this  process  wa.ii  work  well,  as  it 
happens,  such  a  structure  is  usually  *  gooa,  logical 
arrangement  of  the  material,  reflecting  the 
relationsnips  inherent  in  the  content. 

The  level  and  truncation  controls  are  designed  ao  that 
the  necessary  specifications  ray  be  made  with  only  one  or 
two  stroxes  cf  the  keyboard  or  keyset.  Tnese  controls 
are  only  the  most  important  of  a  large  set  of 
view-control  parameters  called  "ViEWSPECs. "  other 
VIEW5PECS  control  a  number  of  special  N18  features 
affecting  the  display  format. 

c.  Content  Analysis 

The  NLS  content  analyzer  permits  automatic  searching  of  a 
file  for  statements  satisfying  some  content  pattern 
specifieo  py  the  user.  The  pattern  is  written  in  a 
special  language  as  part  of  the  file  text. 

content  patterns  may  De  simple,  specifying  the  occurrence 
of  some  word,  for  example.  They  may  also  be  nignly 
complex,  specifying  the  order  of  occurre  ce  of  two  or 
more  strings,  the  absence  of  son**  text  co.  struct, 
conditional  specif icaticns,  etc.  Simple  patterns  >re 
extremely  easy  to  write;  complex  one*  are  correspondingly 
more  difficult, 

d.  "Keyword"  System 

a  ''keyword  statement"  is  a  named  statement  which 
references  other  statements  in  the  file  ty  name,  in  a 
special  format.  The  name  of  the  keyword  statement  is 
then  understood  to  be  a  "keyword"  aptlyirg  to  the 
statements  referenced  by  the  keyword  statement. 

Suppose  that  a  file  contains  a  list  of  keyword 
statement*.  The  user  may  study  this  list  and  select 
several  keywords  vitn  the  Keyword  select  command 
(pointing  to  the  keywords  with  the  mouse). 
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He  may  specify  a  weight  from  1  to  10  for  each 
Keyword;  if  no  weight  is  specified,  a  weight  of  1 
is  assumed. 

When  the  user  tfivea  the  Keyword  Execute  command,  a 
scarching/scoring  process  ia  executed*  Each  of  the 
selected  Keyword  statements  is  scanned  for  the  names 
of  statements  that  it  references.  Eacn  referenced 
statement  receives  a  "score"  equal  to  the  weight  cf 
the  keyword.  If  a  statement  ia  referenced  in  more 
than  one  Keyword  statement,  the  scores  aad. 

when  this  process  is  completed,  nls  constructs  a 
display  picture  showing  only  the  statements  tnat  hive 
received  nonzerc  scores,  in  order  of  decreasing 
score*# . 

in  other  words,  each  Keyword  is  tne  name  of  a  statement 
tnat  defines  sene  category  of  statements  in  the  file. 

When  a  user  selects  ar.d  weights  Keywords,  he  is 
expressing  nis  interest  in  certain  of  these  categories. 
NLS  then  displays  all  of  the  statements  in  these 
categories,  beginning  with  the  "most  interesting.-' 

because  the  relationships  usea  in  tnis  system  are  set  up 
explicitly  wnen  a  user  writes  Keyword  statements,  the 
system  is  very  flexible  although  not  highly  automated. 

It  nay  be  regarded  as  a  generalized  method  of  reordering 
come  cf  the  statements  in  a  file  on  the  basis  of 
user-selected  criterie  chosen  from  a  supplied  list  (the 
Keyword  statements) . 

Note  that  this  reordering  is  on  the  display,  not  in 
the  file  proper,  ihe  file  proper  is  not  affectsd  in 
anv  way,  except  that  the  list  of  selected  Keywords  and 
weight s  is  saveu  ir.  the  file. 

This  list  may  be  displayed  on  command.  Individual 
Keywords  may  be  deleted  from  the  list  or  their 
weights  charged,  or  the  whole  list  can  be  deleted 
on  command. 

e.  LinK  jumping 

A  "link"  ia  a  string  of  text,  occurring  in  an  ordinary 
file  statement,  which  indicates  a  cross-reference  of  some 
Kind,  It  may  refer  to  another  statement  in  the  file,  or 
to  a  statement  in  some  other  file,  possibly  belonging  to 
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another  NLS  user.  The  text  of  the  link  Is  notn 
human-readable  and  macnine-readable,  and  the  command  Jump 
to  Link  permits  the  user  to  point  to  the  link  with  the 
mouse  and  immediately  see  the  material  referred  to. 

An  example  of  a  link  is  {smith,  Rians,  Longrange jebtng ) . 

The  first  item  in  the  link  indicates  tnat  the 
referenced  file  belongs  to  a  user  named  sm itn;  the 
second  ie  the  name  cf  the  file;  the  third  is  the  name 
of  a  statement  in  the  file  (a  statement  number  nay 
also  be  used);  and  the  string  of  characters  following 
the  colon  control!  tne  VIEWbPECs  to  set  up  a 
particular  view  of  the  material. 

The  use  of  interfile  links  permits  the  construction  cf 
large  linked  structures  made  up  of  many  files,  and 
study  of  uhese  files  as  if  they  were  all  sections  of  a 
single  document, 

3.  Modification 

A  large  repertoire  of  editing  commands  is  provided  for 
modification  of  files.  The  basic  functions  are  insert. 
Delete,  Move,  and  Copy, 

These  functions  operate  upon  Various  kinds  01  text  entities, 
Within  statements,  they  may  operate  upon  single  characters, 
words,  and  aroitrary  strings  of  text  defined  oy  pointing  to 
the  first  and  last  characters. 

This  set  of  commands  is  not  restricted  tc  operation 
vithin  one  statement  at  a  time;  for  example,  a  word  nav 
be  moved  or  copied  from  one  statement  to  another. 

The  editing  functions  also  operate  at  the  structural  level, 
taking  statements  or  sets  of  statements  as  operands,  a 
number  of  special  entities  have  oeen  defined  for  this 
purpose*  for  example,  a  "branch"  consists  of  some  specified 
statement,  plus  all  of  its  suostatenents,  plus  all  of  their 
substatements,  etc,  A  branch  can  be  deleted,  moved  tc  a  new 
position  in  the  structure,  etc. 

As  noted  above,  the  modification  activity  tends  to  merge,  in 
practice,  with  study  and  composition. 
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E.  Summary 

It  must  be  noted  tnat  MS  is  not  a  system  designed  for  general 
usage,  but  a  specialized  tool  aesigned  for  a  group  of  people 
working  on  the  development  of  computer  aids  to  numan 
intellectual  processes.  It  is  for  tnis  reason,  for  example, 
that  ;!LS  is  not  really  a  text-editing  system  oriented  toward 
hard-copy  production,  but  ratner  something  simultaneously  more 
general  and  more  specialized. 

It  is  in  the  process  of  manipulating  a  file  --  studying  it, 
making  modifications,  adding  new  material  as  an  integrated 
process  lasting  for  minutes  or  nours  at  a  time  and  having  a 
continuity  extending  for  days,  weeks,  or  even  years  --  that  the 
real  benefit  of  NLS  appears. 

An  MS  file  tends  to  become  an  evolving  entity,  subject  to 
constant  modification,  updating,  and  reevaluation.  Its 
development  may  have  r.o  clearly  defined  endpoint.  It  may 
cease  to  ,»xist  as  a  file  by  being  incorporated  in  another 
file,  or  .t  nay  eventually  be  abandonee;  however,  it  will 
probably  never  be  "finished”  in  the  usual  sense  of  the  word. 

Continuous  use  of  NLS  to  store  ia^s,  study  the-,  relate 
then  structurally,  and  cross-reference  them  results  in  a 
superior  organization  of  idea*  and  s  greater  ability  to 
manipulate  them  further  for  special  purposes,  as  the  need 
arises  --  whether  the  "ideas”  are  expressed  as  natural 
language,  a«  data,  as  programming,  or  as  graphic 
information, 

II  The  Typewriter-oriented  Documentation-Aid  system  (TODAS) 

TODAS  is  a  text-handling  system  designea  as  a  "typewriter" 
counterpart  to  NLS.  In  principle,  TODAS  can  be  operated  from  a 
Teletype  or  any  other  sort  of  hard-copy  terminal,  including 
terminals  linked  to  the  910  through  acoustic  couplers  and  ordinary 
telephone  lines  (as  epposea  to  NLS,  which  requires  special 
transmission  arrangements) . 

The  present  implementation  allows  for  the  use  of  Teletype 
Models  33,  33,  and  37,  Termmet  and  Execuport  terminals  (the 
letter  having  a  built-in  acoustic  coupler),  and  NLS  display 
terminals . 

Each  cl  these  terminals  has  its  own  character  set,  no  two  sets 
being  exactly  the  same  except  Teletype  Models  33  and  3i.  As  a 
result,  special-character  assignments  are  device-dependent.  A 
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TODAS  feature  allows  tne  user  to  redefine  characters  at  will  to 
•  uit  nifl  immediate  purposes. 

The  primary  purpose  of  TODAS  is  for  access,  within  the  ahpa 
Computer  Network,  to  the  NetworK  Information  Center  (uic)  operated 
by  ARC.  T0Da3  will  give  Network  users  access  to  files  of 
information  createa  either  with  TODAS  or  with  N I, S ,  since  files 
created  with  the  two  systems  are  identical  in  structure  ani 
format. 

TODAS  has  many  of  the  same  capabilities  as  MLS  for  the 
manipulation  of  text;  it  differs  from  NLS  as  required  by  the  use 
of  t  "typewriter"  device  instead  of  a  display.  Tne  important 
differences  arise  from  the  Tact  that  TODAS  has  no  analog  cursor 
device  to  correspond  to  the  NLS  mouse* 

For  this  reason,  molting  of  text  within  a  statement  cannot  e* 
done  by  means  resembling  those  of  NLS,  since  all  of  the  NLS 
editing  operands  are  indicated  by  the  user  with  tne  mouse. 

TODAS  uses  two  alternative  metncos. 

One  is  the  loDAS  "alter"  command,  which  operates  very  much 
like  the  "modify"  command  of  the  WED  line-editin,  system 
developed  by  Project  genie  at  UC.  "Alter"  creates  a  new 
statement  to  replace  the  original  one,  by  going  through  the 
original  from  beginning  to  end;  unoer  user  control, 
characters  are  (l)  copied  from  the  old  statement  to  the  new, 
(2)  skipped  over,  or  (3)  inserted  ir.tc  the  new  statement 
from  the  keyboard. 

The  other  is  the  TODAS  "substitute"  command,  which  allows 
the  user  to  specify  that  a  certain  string  of  characters  in 
the  statement  is  to  be  found  py  TODAS  and  replaced  with 
another  specified  string. 

At  the  structural  level  (where  the  user  wisnes  to  manipulate 
statements  and  sets  of  statements  as  units),  NLS  permits  the 
'»aer  to  identify  statements  by  pointing  with  the  mouse;  TODAS 
requires  that  statements  be  identified  from  the  keyboard. 
Considerable  flexibility  is  provided  in  t;.is  operation. 

The  user  may  identify  a  statement  directly  by  typing  its 
statement  number  or  its  name;  he  may  also  identify  it 
indirectly  by  specifying  its  structural  relationship  to  some 
other  statement  whose  numoer  or  name  he  knows  off-hand. 

Indirect  specif ication  corresocnds  to  the  use  of  NLS 
commands  such  as  "jump  to  head,"  "jump  tc  successor, " 
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etc.,  but  with  the  added  feature  that  relationships  nay 
be  concatenated  «-  thus  the  user  nay,  in  a  single 
operation,  specify  a  complex  relationship  such  as  tne 
successor  of  the  first  substatemtnt  of  the  predecessor  of 
a  given  statement, 

A  special  TODAvS  capability  not  yet  implemented  in  NLS  is 
"executable  text." 

A  T0DA5  statement  may  consist  of  the  string  of  characters 
that  a  user  would  type  from  the  keyooarn  to  perform  some 
complex  sequence  of  operations,  inis  statement  may  then  be 
executed  with  a  special  command,  and  tne  result  will  be 
exactly  as  if  the  user  had  actually  typed  these  characters, 
causing  the  sequence  to  be  carried  out. 

The  sequence  may,  in  principle,  be  arbitrarily  complex;  an 
executable  statenent  might,  for  example,  contain  tne 
following  sequence: 

(1)  Load  a  file  whose  name  is  specified  elsewnere  in  the 
current  file 

(2)  Search  this  file  with  the  content  analyzer,  finding 
statements  with  a  specified  pattern  of  content 

( 3 ?  write  these  statements  out  in  a  temporay  "buffer" 

file 

(a)  Reload  the  original  file 

(5)  Copy  the  statements  in  the  "buffer"  file  into  a 
specified  location  in  the  working  file, 

A  special  "switch"  character  may  be  used  in  the  executable 
text,  fchen  the  switch  character  is  encountered,  execution 
of  the  text  is  interrupted  and  control  reverts  to  the 
keyboard.  Tne  user  then  enters  part  of  the  control  sequence 
manually)  when  he  types  the  sitch  character  from  tne 
keyboard,  execution  of  the  executable  statement  resumes  at 
the  point  where  it  left  off.  This  features  affords  great 
flexibility,  since  it  allows  part  of  the  sequence  tc  be 
specified  ahead  of  ime  and  part  at  "execution  time," 

Besides  its  primary  purpose  as  a  Networx  user's  interface  to  the 
NIC,  TODaS  is  used  within  A*C  as  a  supplemental  tool  to  NLS. 

T0PA3  can  be  used  conveniently  for  many  tasks  tnat  do  not 
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require  the  rapid  display  response  of  nls,  and  n as  the 
advantage  of  creating  significantly  less  load  on  the  overall 
timesharing  system.  We  currently  have  one  clerical  worker,  vno 
is  not  an  NLS  user,  operating  TODAS  routinely  for  entry  of 
information  and  for  some  limited  retrieval  work. 

Additionally,  we  find  TODAS  useful  for  remote  accessing  of  cjr 
system.  We  have  made  TODAS  availaoie  to  selected  consultants, 
who  use  home  terminals  with  acoustic  couplers,  and  regular  ARC 
personnel  occasionally  do  work  from  their  homes  0/  tne  same 

means. 

The  prototype  version  of  TOLAS  went  into  service  in  seDtenoer 
1969;  a  second  version,  with  greatly  expanded  capaoilities,  Became 
operational  early  in  1970. 

Ill  Output  Facility 

NLS  and  TODAS  tooth  use  the  same  facilities  for  producing  formatted 
hard-copy  output  from  NIS/T0D4S  files. 

The  devices  in  ordinary  use  at  ARC  for  hard-copy  output  are  a  line 
printer  that  produces  upper/lcwer-caae  print  of  adequate  quality 
for  local  use,,  and  a  pacer-tape-driver.  automatic  typewriter  used 
for  final  output  of  reproducible  copy  for  reports,  proposals,  etc. 

The  output-processing  program  (known  as  "PASSk")  can  be  controlled 
toy  the  user  to  a  consideratole  extent.  Tnis  is  done  by  means  of 
"directives "  embedded  in  the  file  text,  Tne  directives  can  ce 
used  to  reset  page  parameters,  control  pa*e  numbering,  and  turn 
various  format  features  "on"  or  "off." 

For  example,  directives  can  toe  used  tc  suppress  indentation  of 
statements  or  cnange  the  amount  of  indentation,  to  create 
"running  heads"  that  are  automatically  printed  at  th  tor  of 
each  page,  suppress  statement  numbers,  etc.  one  cf  the 
directives  causes  all  directives  to  pe  suppressed  from  the 
output, 

in  addition  to  the  line  printer  and  the  automatic  typewriter, 

PASSk  can  output  a  file  to  magnetic  tape,  appropriately  fornatted 
to  drive  CRT«to*»fiim  conversion  equipment  for  production  of 
microfilm. 

In  all  cases,  the  user  may  elect  to  output  an  entire  file  or  only 
part  of  the  file,  in  the  latter  case,  he  nay  c  use  output  tc 
begin  at  some  specified  point  in  the  file  instead  of  at  the 
beginning,  and  he  may  cause  the  printout  *0  be  limited  by  the  sane 
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kinds  of  criteria  that  nay  be  used  on  tne  display  --  i.e.,  content 
analvsia,  1‘nited  mumper  of  structural  levels3  etc, 

IV  Glossary  of  Soecial  NL3/T0T AS  Terminology 

BRANCH:  A  specified  statement,  plus  all  of  its  substructure  -- 
i  e.  all  of  its  suostatenents ,  plus  all  of  tneir  subatater.ents , 
et'.c 

BUG:  Tne  nark  on  the  screen  vhicn  is  moved  by  tne  mouse  and  which 
i*  used  for  selecting  (pointing  to)  entities  on  tne  display. 

when  tne  bug  is  "active,"  i.e.  wnen  a  selection  can  be  made,  it 
appears  as  an  up-arrow;  when  it  is  inactive  it  appears  as  a 
plus  sign. 

CHARACTER:  Any  let  ,  digit,  punctuation  naik,  soace,  tao,  or 
carriage  return;  an  indivisible  entity. 

CHORD:  A  combination  of  keys  on  the  Keyset  (see  KEYSET). 

END :  The  last  statement  in  any  branch;  specified  by  specifying  the 
braneh. 

FILE :  A  complete  tree  structure  of  statements  with  a  single  root 
(the  origin  statement'. 

FILENAME :  The  name  of  a  file.  It  apoetrs  as  tne  first  word  in  tne 
origin  statement  cf  an  existing  file,  and  must  be  supplied  by  the 
user  in  creating  a  new  file. 

GAP  CHARACTER:  Any  space,  tab,  or  carriage  return. 

OCHARi  Abbreviation  for  GAP  CHARACTER. 

GROUP:  A  subset  of  a  plex,  consisting  of  all  trancnes  from  one 
specified  branch  to  another,  inclusive. 

HEAD:  The  first  statement  in  a  sublist. 

The  head  is  specified  by  pointing  to  any  statement  in  the 
sublist. 

INVISIBLE:  Any  consecutive  string  of  gap  characters,  bounded  bv 

ibut  not  including)  printing  characters  or  the  end  of  a  statement: 
see  PRINTING  CHARACTER,  GAD  CHARACTER,  STATEMENT. 

Specified  by  pcintir.f,  to  any  character  in  the  string.  If  a 
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single  printing  character  lying  Detween  two  mvisioles  is 
pointed  to,  both  invisible*  Cano  the  printing  cnaracter)  are 
selected. 

KEYSET :  The  device  at  the  left-rand  aide  of  the  console.  *  hen  a 
combination  of  Keys  (a  chord)  is  depressed  on  the  Keyset,  the 
effect  is  the  same  as  striking  a  Key  on  the  Kevooaro. 

KEYWORD:  The  name  of  a  "Keyword  statement." 

KEYWORD  STATEMENT i  A  statement  which  lists,  in  a  special  format, 
the  names  of  all  statements  in  the  sane  file  that  fall  into  some 
arbitrary  category. 

The  "Keyword  system"  of  NLS/TQDaS  commands,  operating  aoon 
keyword  statements,  performs  information-retrieval  operations 
based  on  the  sets  of  statements  defined  in  Keyword  statements. 

LABEL*  A  string  of  text  placed  in  a  picture  oy  means  of  a  command 
in  the  vector  package, 

LEVADji  The  specification  of  level  when  a  statement,  branch,  plex, 
or  group  is  newly  created  or  moved. 

LEVEL*  The  "rank"  of  a  statement  (see  STATEMENT)  in  the  hierarchy 
of  the  file  {see  FILE) . 

The  level  is  equal  to  the  numcer  of  fields  of  letters  or  digits 
in  the  statement  number;  thus  statement  3  is  a  first-level 
statement,  statement  kalOg}  is  a  fifth-level  statement,  etc. 
Level  la  nf  great  importance  in  understanding  the  hierarchical 
structure  of  an  NLS  file. 

MOUSE:  The  device  at  the  right-hand  side  of  tne  Keyboard.  «hen  it 
is  rolled  around  on  the  tabletop,  it  causes  the  bug  to  move 
correspondingly* 

NAME:  It  the  first  word  of  a  statement  is  enclosed  in  parentheses, 
it  is  the  KAHE  of  the  statement. 

The  command  jump  to  Name  can  then  be  used  to  place  the 
statement  at  the  top  of  tne  display.  This  is  done  by  entering 
the  name  from  the  Keyboard  or  Keyset,  or  by  finding  an 
occurrence  of  the  name  as  text  on  the  display  and  pointing  to 
it  with  the  bug. 

ORIGIN :  The  firet  statement  in  a  file;  it  contains  information 
about  the  file,  plus  any  other  text  the  user  inserts,  it  has  a 
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level  of  o,  and  heru ;  no  statement  numoer. 

PATTERN:  A  string  of  special-language  text  in  a  statement  which 
may  be  compiled  via  the  command  Execute  content  Analyzer,  «hen 
compiled,  it  produces  a  program  that  is  used  oy  the 
content-analyzer  icature. 

PCHAH:  Abbreviation  for  PRINTING  CHARACTER. 

PLEXi  Another  name  for  a  SUBSTRUCTURE,  used  in  command 
specifications. 

A  Plex  is  specified  ty  pointing  to  any  one  of  its  nignest-levei 
statements . 

POINTER:  A  string  of  up  to  three  characters  wnicn  is  attached  to 
acme  character  in  the  text  with  the  pointer  Fix  command# 

PREDECESSOR:  The  statement  preceding  a  specified  statement  in  a 
SUBLIST. 

PRINTING  CHARACTER:  Any  letter,  digit,  or  punctuation  mar*. 

SOUPCE;  The  statement  of  which  a  specified  statement  is  a 
supfltatenent. 

SIGNATURE:  information  stored  with  a  statement  (and  displayed  on 
command)  giving  the  initials  of  tne  user  who  created  tne  statement 
(or  most  recently  modified  it)  ana  the  time  and  date  when  this 
occurred, 

STATEMENT*  The  basic  structural  unit  of  a  file  of  text  in  N’LS. 
formally,  it  is  a  string  of  text  and/or  pictures  which  is  bounded 
at  the  Beginning  py  the  end  of  the  previous  statement  or  the 
beginning  of  the  file,  and  pounaed  at  the  end  oy  the  beginning  of 
another  statement  or  the  end  of  the  file. 

Statements  are  arranged  m  a  tree  structure  or  hierarchy  an*S 
are  assigned  "statement  numbers'1  which  indicate  their  positions 
in  the  structure.  Each  statement  has  a  number,  made  up  of 
alternating  fields  of  digits  and  letters;  the  numoer  of  fields 
indicates  the  "level"  of  the  statement  (see  LE*.  EL), 

A  statement  is  specified  ov  pointing  to  any  character  in  the 
string. 

SUBLIST:  The  set  of  all  suostatements  of  a  specified  statement 
(not  including  the  suostatements  of  the  substatements ) , 
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SUBSTATEMENT:  A  statement  "XM  la  called  a  suostatement  of  another 
statement  Myw  if  It  la  deeper  m  the  atructure  than  "  Y ,  if  It 
follows  " y*  M  and  if  there  is  no  intervening  nigner-order 
statement.  HYM  is  called  the  source  of  ''X.”  ine  statement  number 
of  M X"  will  be  the  same  aa  that  of  "Y"  except  that  it  will  have 
one  more  field  at  the  end.  The  value  of  this  field  fives  its 
ordinal  poaition  m  a  "sublist"  cf  the  subatatements  of  "Y." 

A  aubstatement  is  specifier  Dy  pointmr  to  the  source 
statement . 

SUBSTRUCTURE:  The  set  of  all  aubatatementa  of  a  specified 
statement,  plus  all  their  subatatements,  etc.  until  no  more  are 
found.  The  set  of  all  tranches  defined  by  statements  in  the 
subliat  of  a  given  statement. 

SUCCESSOR!  The  statement  following  a  specified  statement  in  a 
sublist. 

TAIL!  The  last  statement  in  a  sublist. 

The  tail  is  specified  by  pointing  to  any  statement  in  the 
sublist. 

TEXT:  Any  string  of  characters  within  a  statement,  bounded  by 
(and  including  two  specified  characters:  see  CHARACTER, 

STATEMENT. 

TRAIL:  A  set  of  statements  in  a  file,  whicn  car  be  displayed 
sequentially  by  using  the  trail  feature. 

VECTOR:  A  line  m  a  picture. 

VISIBLE:  Any  consecutive  string  of  printing  characters,  bounded 
by  (but  not  including;  gap  characters  or  the  end  of  a  statement: 
see  PRINTINQ  CHARACTER,  GAP  CHARACTER,  STATEMENT. 

Specified  by  pointing  to  any  character  in  tne  string,  if  a 
single  gap  character  between  two  visibles  is  pointed  to,  then 
both  visibles  (and  the  sap  character)  are  specified. 

WORD:  Any  consecutive  string  of  letters  and/or  digits,  bounded  by 
(but  not  including)  any  otner  types  of  characters  or  the  end  of  a 
statement:  see  STATEMENT « 

Specified  by  pointing  to  any  character  in  the  string.  If  a 
single  character  is  pointed  to  which  is  not  a  letter  or  digit 
and  lies  between  two  words,  then  both  wcras  (ana  the  single 
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character)  are  «pecified. 
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I  P reface 

Ecr  hi*  dissertation  study  at  Stanford  University,  Dr.  David  a. 
Evans  (then  an  ARC  staff  member  and  associates  vitn  the  Management 
Systems  Research  Activity)  developed  tne  cr.se  for  augmentation  of 
planning  teams. 

His  thesis  (Ref,  1),  written  with  NiS,  13  over  five  hundred  pages 
in  length,  in  it  he  presents  for  the  planning  community  a  brc*  i 
description  of  ARC'S  augmentation  approach,  developments  achieved 
by  ARC,  and  extrapolationo  relevant  to  the  planning  community. 

As  a  special  case  study,  Dr,  Evans  integrated  the  considerations 
and  possibilities  for  the  Dialogue  support  System,  as  developed 
within  the  ARC  over  a  number  of  years  ana  as  studied  specially  ov 
Evans  under  this  contract. 

Selected  extracts  from  his  tneeis,  sligntlv  condensed,  are 
included  below  as  a  good  source  of  relevant  concept  material  aoout 
the  DSS.  These  may  be  considered  as  trial  design  notes;  the  final 
designs  for  the  various  parts  of  tne  DSS,  and  their  order  of 
development,  are  yet  to  be  developed, 

II  Basic  Components  cf  the  Dialogue  support  System  US 3) 

The  DSS  can  be  considered  to  have  two  basic  parts:  (l)  the 
Journal,  and  (2)  a  set  of  NL3  features  especially  designee  to 
operate  on  the  Journal. 

A.  The  Journal 

Ch®  of  the  most  dramatic  things  NLS  enaoles  its  user  to  do  is 
operate  on  and  maintain  extremely  "plastic”  and  malleable 
records  of  his  thought  and  worx. 

This  ever-changing  plasticity  is  the  root  of  basic  difficulties 
in  extending  NLS  for  dialogue  support.  When  members  of  a  team 
are  contributing  to  a  plan  or  design,  one  of  the  most  important 
things  is  that  the  "targets"  of  their  contributions  remain 
stationary,  as  if  in  a  diary,  or  Journal,  ironically,  the 
design  of  a  "Journal"  to  maintain  stationary-target  records  of 
the  transactions  of  members  of  a  team  proved  to  be  innovative 
in  the  NLS  environment,  whereas  it  would  be  "normal’-*  if  we  were 
dealing  with  simple  pencil  and  paper. 

The  Journal  is  a  special  repository  for  NLS  files  vhicn  may  be 
"sent  to  the  Journal"  and  no  longer  modified,  or  changed  in  any 
way. 
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The  design  oojective  of  the  Journal  is  to  provide  the  basis  for 
evolution  of  a  diary  for  a  team,  sufficiently  rich  to  play  the 
same  role  as  a  personal  diary  plays  when  used  for  record 
Keeping,  and  as  the  oasis  for  composition,  reflection,  and 
extended  memory. 

B.  Operations  Based  on  Journal  Entries 

The  second  component  of  the  DSS  is  a  collection  of  special  NL3 
features,  designed  to  ma<e  the  Journal  useful  as  the  oasis  for 
supporting  team  dialogue. 

The  Journal  provides  the  team  members  with  a  chronicle  of  their 
contrioutions  to  plans  and  designs.  NL3,  as  extended  for  use 
as  part  of  the  DSS,  is  a  vehicle  that  (for  example)  enables 
team  members  to  annotate  contributions  from  others,  to  call  for 
specific  action,  to  maKe  synopses  of  records  relevant  to 
specific  issues,  and  to  raaKe  contributions  to  the  evolution  of 
plans  and  designs  that  are  efficiently  and  appropriately 
integrated  and  connected  to  the  entire  record  of  activity. 

At  another  level,  NLS  is  a  vehicle  enabling  team  mempers  to 
"browse*  in  tne  Journal,  to  arrive  quickly  and  efficiently  at 
an  understanding  of  the  status  of  plans  and  designs  that  are 
being  documented,  monitored,  or  evolved  through  the  medium  of 
the  DSS. 

Interspersed  with  this  and  the  previous  roles,  extended  nls 
features  enable  team  members  to  retrieve  information  from  the 
Journal,  to  modify  and  update  thin  information,  and  to  return 
it  to  the  Journal  without  destroying  the  original 
contributions . 

Ill  Design  of  Architecture  for  the  Journal 

A.  Introduction 

The  boundary  between  the  Journal  proper  ana  the  NLS  features 
that  support  it  is  not  cloarly  defined,  as  those  features 
necessary  for  servicing  tne  Journal  also,  indirectly,  support 
the  special  DSS  features.  However,  the  discussion  can  oe 
simplified  by  means  of  this  division. 

B.  stationary  Targets 

The  ideal  record  system  for  dialogue  support  would  be  some 
large,  central,  evolving  record  that  would  Keep  tracK  of  the 
team1®  activity  as  team  members  contributed  modifications,  new 
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idea*,  new  designs,  specifications,  and  so  on,  over  ti-e.  *c 
nave  only  to  consider  the  problems  raised  bv  the  oaslc 
f ile-handling  operations  of  the  current  NLS  to  appreciate  the 
difficulty  of  creating  such  an  evolvintr  record  of  transactions. 

In  any  attempt  to  use  files  for  dialogue  purposes,  the  first 
problem  encountered  arises  from  multiple  access  to  files,  when 
a  file  is  strictly  the  "property”  of  its  author,  dealing  with 
material  for  which  he  alone  has  prime  responsibility ,  the  file 
owner  can  quite  easily  Keep  track  of  its  development. 

However,  when  several  individuals  make  active  use  of  a  file, 
it  becomes  very  difficult  for  the  individuals  to  avoid 
canceling  each  other's  work  or  otherwise  interfering  with 
each  otner.  They  cannot  all  access  tne  file  simultaneously, 
and  so  copies  are  created;  soon  there  are  multiple  copies, 
each  copy  containing  changes  and  additions  made 
independently  oy  varicut  users.  It  is  then  impossiole,  in 
the  general  case,  to  put  these  copies  pack  together  in  such 
a  way  that  all  tne  work  done  cn  the  separate  copies  is 
preserved. 

The  proolem  is  much  like  trying  to  hit  a  moving  target  in  the 
dark,  and  the  desired  solution  is  to  find  some  way  to  make  the 
target  stop  moving  --  nence  the  phrase  "stationary  targets," 

The  existing  capabilities  of  NLS  and  the  file-handling 
facilities  used  by  NLS  are  not  adequate  for  achieving  this. 

Tor  example,  it  would  be  possible  with  existing  capabilities 
to  give  all  files  a  read-only  status,  so  that  once  a  file 

was  created  it  could  never  pe  modified.  This  would  overcome 

many  of  the  problems  of  multiple  access;  however,  it  would 
also  destroy  most  of  the  power  and  usefulness  of  NLS  as  a 
tool  for  manipulating  information. 

Likewise,  it  would  be  possible  to  give  all  files  a  public 
read/write  status,  permitting  any  member  of  the  team  to 
modify  any  file  at  will,  it  can  be  seen  that  this  would 
lead  to  immediate  chaos i  a  team  member  working  on  a  file 
and  wishing  tc  make  reference  to  another  file  would  have  no 

assurance  that  the  referenced  file  still  contained  the  same 

information  as  when  he  looked  at  it  last. 

The  concept  of  the  journal  is  a  way  to  create  stationary 
targets  without  the  crippling  effect  cf  a  blanket  read-only 
policy  or  the  anarchy  of  a  blanket  public  read/write  policy. 
Files  "entered  in  the  Journal"  have,  in  effect,  read-only 
status,  but  numerous  capabilities  are  added  to  compensate  for 
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this;  moreover,  the  Journal  contains  only  selected  files  vhicn 
are  considered  to  be  "ready"  to  become  stationary  targets. 

C.  The  Journal 

The  Journal  is  a  public  repository  for  information  of  concern 
to  the  team  of  users.  A  file  sent  to  the  Journal  becomes  a 
public  record.  In  principle*  at  least,  it  cannot  in  any  way  oe 
altered,  or  retracted. 

The  autnor  has  "gone  on  record"  with  the  statement  made  oy 
the  file's  content.  He  may  keep  a  copy  of  the  file  entered 
in  the  Journal,  and  make  modifications  and  corrections  in 
that  eocy,  but  cannot  replace  the  original  file  in  the 
journal  by  over-writing  it  with  the  revised  version.  Both 
the  original  ana  revised  versions  may  be  entered  In  the 
Journal. 

A  basic  Journal  function  is  to  proviae  users  with  mechanisms 
and  aids  to  recognize  that  "later  versions"  m  the  journal 
naye  been  entered,  and  to  provide  users  with  features  to 
enable  them  to  retrieve  and  display  the  multiple  versions  of 
a  given  file. 

in  keeping  with  other  (non-computerized)  Journals,  the  only 
ordering  imposed  on  Journal  entries  is  chronological. 

In  NL3,  "Journal"  becomes  a  distinct  user  name,  with  a  status 
similar  to  all  other  users. 

However,  the  Journal  adds  a  second  distinct  domain  of  files  to 
the  NL3  file  universe.  Journal  flits  have  special  features. 
They  are  all  read-only.  They  possess  two  parts  --  the 
text/graphies  portions  written  oy  their  author,  and  clocks  of 
data  containing  information  added  to  the  file  after  submission 
to  the  Journal. 

The  first  component  is  totally  frozen:  once  a  file  is  "sent 
to  the  Journal"  the  "maximum"  user  representation  for  that 
file  may  not  be  subsequently  altered. 

But  the  second  component,  data  blocks,  may  be  changed 
through  the  addition  of  new  data  over  time, 

1.  Journal  Entries 

Although  wo  have  been  discussing  "files"  in  the  Journal,  we 
should  refer  to  a  module  of  information  in  the  Journal  as  an 
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"entry."  From  the  viewpoint  of  the  NLS  file  system,  an 
entry  is  synonymous  with  a  file.  However,  we  wish  to 
emphasize  the  notion  of  collecting  information  from  manv 
files  together  into  one  module,  and  sending  that  module  to 
the  Journal  as  an  entry*  For  tnis  reason,  we  will  persist 
with  the  terminology  '’entry"  rather  than  "fi*e"  wnen 
discussing  the  Journal  from  the  point  of  view  of  a  user 
(contrasted  to  the  viewpoint  of  the  system), 

D.  Sending  an  Entry  to  the  Journal 

Because  of  the  existence  of  two  file  universes  (regular  NLS 
files,  and  Journal  entries)  a  user  is  not  compelled  to  summit 
all  of  his  filss  to  public  scrutiny. 

He  may  Keep  his  personal  collection  of  files  containing  nis 
notes,  plans,  special  reminders,  etc.,  separate  from  the 
collection  of  files  he  submits  to  the  Journal, 

within  this  personal  collection  he  retains  tne  option  of 
controlling  read  and  write  access  by  other  users.  He  may, 
for  instance,  have  several  files  that  contain 
private/confidential  information  that  is  of  no  concern  to 
the  team  as  a  whole. 

However,  the  decision  to  submit  one  of  his  own  files  to  the 
Journal  is  not  totally  the  prerogative  of  the  user  himself, 
unless  all  his  files  have  private  status. 

Files  stored  under  a  given  user  name,  with  other  than 
private  status,  may  be  entered  to  tne  Journal  by  any  other 
user.  This  is  similar  to  the  procedure  of  having  testimony, 
or  a  speech,  or  other  data,  read  into  the  (Congressional) 
Record, 

However,  in  most  cases,  journal  entries  are  submitted  by  the 
user  who  has  the  file  (or  component  files)  stored  under  his 
name,  as  part  of  the  standard  NLS  fil«  universe. 

For  one  user  to  submit  another's  file  to  the  journal,  he  must 
first  load  that  file,  maKe  a  temporary  copy,  and  submit  that 
copy  as  a  Journal  entry  as  if  it  was  one  of  his  own  "normal" 

NLS  files. 

Entering  a  file  to  the  Journal  involves  the  following 
operations! 

(1)  A  copy  of  the  file  being  submitted  is  made. 
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(2)  That  copy  is  again  copied,  by  the  system,  and 
(automatically)  written  as  a  new  file  under  the  ua*r  name 
"Journal. "  It  is  Riven  a  new  name,  wnich  is  a  unique 
"Journal  Entry  Nunoer,"  and  set  tc  read-only  status. 

(3)  The  user  suomitting  this  file  is  given  &  "receipt"  by 
tne  system,  indicating  that  entry  to  tne  Journal  nas  been 
successful. 

The  result  is  that  a  "shaosnot"  of  the  user's  file  has  been 
recorded  as  a  Journal  entry.  The  user  nas  complete  control 
over  the  VIDrfSPECS  controlling  the  view  and  amount  of  the  file 
submitted  to  the  Journal.  For  instance,  if  ne  so  chooses,  the 
user  may  submit  only  the  first  level  statements  in  the  file. 

Or  he  may  submit  only  selected  statements  in  the  file  --  for 
instance,  only  those  that  satisfy  a  specific  content  pattern. 

He  may,  of  course,  choose  to  employ  no  special  VIEkSPECS,  and 
submit  the  entire  file  to  the  Journal.  The  VIEWSPECs  used  at 
time  of  entry  to  the  journal  determine  the  maximum  suboecuent 
view  for  that  Journal  entry. 

Subsequent  readers  of  the  journal  entrv  may  employ  all 
available  VlErfSPECS  to  help  them  study  the  content  of  the 
entry,  but  are  constrained  to  this  "maximum"  view.  This  means, 
for  example,  if  a  file  is  submitted  to  the  journal  with  a  1-1 
VIEWSPEC  (i.e.,  only  too  level  statements,  and  only  one  line  of 
these),  suDsequent  readers  can  view  no  more  information  in  that 
entry,  otner  tnan  the  1-1  view,  even  if  he  usee  a  VIE*SPEC  suen 
as  ALL-ALL  (i.e.,  ail  statements,  and  all  lines  of  each 
statement) . 

Thus  the  result  of  this  entry  procedure  is  the  creation  of  a 
new  read-only  file,  a  stationary  target,  under  the  user  name 
Journal,  with  a  unique  Journal  Entry  Number  as  its  name. 

E.  Journal  Entry  linkage  Systems 

Once  we  have  procedures  for  submitting  entries  to  tne  Journal, 
the  next  major  need  concerns  linking  the  individual  stationary 
targets  --  the  journal  entries  --  into  a  faoric  of 
interconnected  information, 

interfile  linke  may  be  used  to  refer  to  specific  locations  in  a 
file  from  any  arbitrary  location  in  another  file.  The 
difficulty  in  this  interfile  linkage  system  is  that  there  is  no 
way  for  a  user  to  discover  'hat  a  particular  entity  (e.g.,  a 
specific  statement)  in  the  file  he  is  reading  is  oeing  referred 
to  by  links  embedded  in  other  files,  or  embedded  in  other 
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ftateme ntff  withiu  the  same  file.  This  basic  weakness  leads  to 
indiscriminate  deletion  or  alteration  of  files. 

To  solve  this  problem  in  the  DSS,  Journal  entries  will  have 
"bacfclinks. "  This  means  that  wnen  a  link  is  established  in  a 
file  (for  instance,  a  file  not  in  the  Journal),  a  special 
marker  will  oe  written  automatically  by  NLS  in  the  appropriate 
location  of  the  referent  file,  indicating  that  a  link  if* 
pointing  at  that  entity. 

This  marker  will  give  subsequent  readers  of  the  referent  .file  a 
visual  signal  that  the  markea  entity  is  tne  target  of  a  link  m 
another  file,  A  new  NLS  command,  JUMP  BACKLINK,  will  make  it 
possible  for  the  user  to  jump  from  the  entity  in  the  referent 
file  ’’back”  to  the  statement  containing  the  link  in  the  source 
file. 

There  are  five  cases  of  file-pair  linkages  tnat  produce 
problems: 

(1)  Linkage  between  two  standard  NLS  files,  A  and  B,  from  A 
to  b,  and  file  A  subsequently  becomes  a  Journal  entry. 

problem:  The  link  in  a  continues  to  refer  to  8,  and  is 
unaware  of  the  formation  of  a  Journal  entry  from  B,  If  B 
is  deleted,  the  link  point*  to  a  non-existent  file. 

Need:  Additional  bookkeeping  to  redirect  links  to  the 
appropriate  Journal  entry  if  B  is  deleted  cr  otherwise 
modified  to  wake  the  link  inappropriate,, 

(2)  Linkage  between  two  standard  NL3  files,  a  and  bD  from  A 
to  B,  and  B  subsequently  becomes  a  Journal  entry. 

Problem:  The  backlink  attached  to  the  referent  entity  in 
b  points  back  to  a,  and  is  unaware  of  the  Journal  entry 
made  from  A  at  a  later  date.  If  A  is  deleted  after  its 
copy  is  sent  to  the  Journal,  subsequent  effort*  to  JUMP 
BACKLINK  on  the  backlink  marker  from  a  in  B  will  yie*d  a 
"no  such"  message. 

Need:  Additional  bookkeeping  to  redirect  tne  backlink  to 
the  appropriate  journa1  entry  if  A  is  ever  deleted  or 
otherwise  modified  to  .ake  the  backlink  inappropriate. 
This  leads  to  the  concept  of  indirect  linking. 
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(3)  Linkages  Detween  two  standard  nls  file*,  A  and  B,  from 
A  to  3,  and  ootn  A  and  d  subsequently  oecome  Journal 
entries . 

Combination  of  problems  ana  needs  of  Cases  1  and  2. 

U?  linkage  frcn  a  journal  entry  to  a  standard  NiS  file 
that  suosequentiy  becomes  «  Journal  er.trv. 

Problem!  Link  in  trie  journal  entry  is  unaware  of  tne 
existe^e  of  tne  Journal  entry  made  .from  j. 

Needs  Bookkeeping  necessary  to  redirect  tne  link*  if 
requested,  o  the  appropriate  Journal  entry  if  so 
requested  oy  tne  user. 

(5)  Linkage  from  a  standard  NLS  file  to  a  journal  entry, 
and  the  standard  NLS  file  subsequently  becomes  a  Journal 
entry* 

Same  as  Case  i  except  we  are  concerned  witn  backlinks 
rather  than  links. 

F.  Other  Basic  Journal  Needs 

Ir.  cur  ‘.rst-pass  discussion  of  journal  architecture  and  needs, 
we  should  consider  two  additional  general  needs,  archiving  and 
cataloguing . 

Archiving  is  necessary  because  the  current  system  has  United 
storage  area  for  files  accessible  to  NLS.  The  only  mass 
storage  devices  presently  available  in  tne  ARC  facility  are 
magnetic  tapes,  *:*  „  so,  at  first,  the  Journal  will  have  a 
sequential  archive.  All  Journal  entries  nave  arcnival  copies, 
Tne  archival  system  provides  a  uacx-up  to  tne  colon  copy  of  a 
Journal  entry  in  case  of  disaster,  and  a  large  tertiary  storage 
area  for  those  entries  not  frequently  referenced,  that  do  not 
have  to  be  kept  continually  in  colon  file  storage  on  the  disk, 

Major  archiving  problems  arise  because  of  additional  data 
{includin'  backlinks)  associated  with  an  entry  after  it  is 
submitted  t -  tne  Journal. 

Files  are  allocated  a  finite  number  of  b.  jCks  on  a 
magnetic  tape  at  the  time  .hey  are  written.  Data  added 
after  the  entry  is  m  •'»  may  be  written  in  this  "slop" 
area  until  it  is  fill  .  dut  from  then  on,  these  data 
must  be  stored  elsewhere,  only  minor  problems  arise  if 
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the  additional  data  can  be  stored  elsewhere  on  tr.e  same 
ttoe,  witn  a  lin*  from  the  original  entry  to  a  special 
file,  eisewnere  on  that  tape,  associated  with  that  entry, 
containing  additional  data* 

However,  when  the  tape  is  filled,  these  data  nave  to  be 
stored  on  a  separate  tape.  This  causes  considerable 
difficulty  when  retrieving  the  entry  and  its  associated  data 
from  the  archive.  There  is  r.o  simple  solution  to  this 
problem  while  magnetic  tape  is  the  arcnival  media.  Thes.* 
problems  will  not  arise  with  random-access  mass-storate 
media. 

The  final  basic  Journal  feature  is  a  catalogue.  Obviously,  a 
Journal  reader  requires  a  guide  to  the  contents  of  the  journal, 
and  this  is  provided  by  the  catalogue. 

The  Journal  Catalogue  will  have  three  principal  parts; 


(1)  Subject  index 

(2)  Citation  list  for  journal  entries 

(1)  Keyword  lists. 

IV  Design  for  Detailed  SIS  features  to  3upport  DSS 

At  Submission  of  an  antry  to  the  Journal 

15  Entry/Reccipt  procedure 

When  a  file  is  submitted  to  the  Journal,  the  first 
operations  are  concerned  with  creating  a  new  journal  entry, 
allocating  a  unique  number  to  that  entry,  and  giving  tne 
sender  a  receipt.  This  receipt  acknowledges  the  entry  has 
been  made  sucessfuliy,  and  supplies  the  sc  der  with 
sufficient  information  to  enable  him  to  locate  and  retrieve 
the  entry  at  a  later  date.  Details  of  this  procedure  are 
illustrated  in  the  following  scenario. 

a.  Scenario;  An try/Receipt  Proecedure 

(13  Assume  tne  user,  X,  has  assembled  a  file  (X,X1)  to  oe 
submitted  to  the  Journalc 

(2)  He  activates  the  new  JL3  command  "ENTER  FILE  TO 
JOURNAL  filename,”  entering  the  filename  XI,  as  the 
operand  for  this  command. 
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(3)  NLS  maxes  &  copv  of  the  file  (X,Xi)  as  a  temporary 
file,  (JOURNAL, T1 )  ,  i.e,,  under  the  user  name  "Journal." 

(It)  Immediately  after  maxing  Vis  net  file,  t:ie  system 
cnecKs  a  special  record,  containing  s  Ijourn^l  Entry 
Number,”  taking  note  of  the  time  and  date  this  cnecK  is 
made.  Journal  Entry  Numoers  nave  the  form  "nnnjmmy." 

"NNn"  is  a  serial  numoer,  ir.  the  range  1  to  z  where  z 
is  arbitrarily  large. 

"J"  is  tne  literal  character  "j,"  indicating  that  the 
number  refers  to  a  Journal  entry. 

"MM"  is  tne  mortn  the  entry  was  subnitted  ;e.g„,  11  » 
November) . 

"Yn  is  the  year  the  entry  was  subnitted  (e.g,,  9  ■ 
1969)  . 

Tne  '  ‘rial  numbers,  nnn,  are  initialized  at  tne  start  of 
each  month, 

Example:  If  'i562Jli$  is  tne  last  entry  submitted  to 

the  Journal  in  the  month  of  November,  1969  (indi-:*  *nx 
that  LS62  entries  were  submitted  in  that  month),  the 
next  Journal  entry  would  be  allocated  the  number 
1J129. 

Assume  that  the  number  in  this  location  at  the  time  of 
this  particular  access  was  U57J119,  and  the  exact  time  of 
access  was  ln51*30,  on  11/13/69.  Once  this  numoer  has 
been  secured,  the  system  updates  the  latest  Journal  Entry 
Number  in  this  location  (to  *57*1  *  L96). 

Tne  system  now  copies  the  file  ( JOURNAL, Tl)  to  a  new 
file  --  a  Journal  entry  with  file  name  L57J119.  It 

sets  the  status  of  tnis  file  to  oublie  read-only,  ana 

notes  the  time  and  date  of  completion  cf  maxing  this 
Journal  entry:  U51.JL5,  11/13/69. 

Once  this  journal  entry  has  oeen  made,  the  system 

returns  a  message  " JF  IL£  (X,X1)  ENTERED  TO  JOURNAL  A3 

NUMBER  U57J119  AT  l&]i7iii5M  to  the  sender  (user  X). 

This  message  remains  on  user  X's  display  until  t 
command  accept  (CA)  is  entered.  Entering  the  CA 
releases  tr.e  file  (X,X1)  for  normal  operations,  and 
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redisplays  the  file.  User  X  is  row  free  to  continue 
his  normal  worn. 

2.  Data  Assembly  Procedures  at  Input  Tine 

The  tine  an  entry  is  submitted  to  the  journal  is  an 
opportune  time  to  capture  data  associated  with  the  entry. 

The  Journal  entry  procedure  will  contain  additional 
operations,  in  which  the  system  interrogates  the  user  to 
obtain  an  abstract  and  special  descriptor  tags  for  the 
entry.  The  abstract  will  ce  used  m  the  Journal  catalogue. 
Descriptor  tags  will  ne  used  for  retrieval  of  entries. 

3,  Collection  System 

Fart  of  the  journal  entry  system  gives  the  user  special  aids 
for  assembling  the  entry  oefore  actual  suomission.  These 
are  compound  operations,  combining  several  simpler  ones. 
These  simpler  operations  include  file  merging  ana  the 
"executable  statement-’  capability, 

B,  Linkages 

Special  linking  features  will  be  added  to  NLS  to  support  the 
DSS  needs,  one  cf  the  most  important  classes  of  these  new 
features  concerns  NLS  links. 

1.  "Link”  as  an  NLS  Entity 

in  the  current  NL3  a  link  is  a  simple  text  construct;  it  is 
not  a  special  entity,  in  the  way  that  characters,  words,  ana 
statements  (for  instance)  are  entities. 

There  is  no  command  DELETE  IIN>  in  current  NLS.  A  linx 
may  be  deleted  using  tne  normal  DELETE  TEXT  command, 
requiring  two  bug  selections,  one  at  each  of  the  link 
parentheses, 

A  special  NLS  entity  "link"  will  be  added  to  NLS.  This  will 
be  of  particular  importance  in  combination  with  indirect 
linking  and  executable  statement  operations. 

To  insert  a  link ,  the  new  command  INSERT  LINK  is  used.  This 
command  requests  user  input  of  data  necessary  to  construct 
the  link,  and  organizes  these  data  in  the  aopropriate  syntax 
(see  below). 
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2.  New  NLS  Lin*  Syntax 

a.  Additional  tin k  Data 


Aaditlonai  -jata  will  do  auaea  to  the  current 
construct.  These  data  are  (a)  Uru  tvoe,  (d) 
date  the  link  was  first  constructed,  or  last 
and  (c)  improved  resolution  to  identify  linx 


NLS  link 
time  arc 
"stamped ,  ■' 
referents . 


Link  type  data  are  one  or  more  descriptor*.,  oem*  a 
simple  text  name,  or  collection  of  names,  indicating 
membership  of  a  class,  or  classes 


Example:  Pcssiole  link  types  woull  be  "footnote," 

"comment,"  "reouttai;M  "owner-evana, "  etc.  A  link 
"owner15  could  be  different  from  the  owner  of  the  file 
in  which  the  link  resided.  Tne  definition  of  these 
types  and  their  respective  mnemonic-  would  be 
determined  by  agreement  among  DSS  users. 


A  moat  important  addition  to  N„s  links  will  be  the  added 
power  to  refer  to  ANY  entity.  In  tne  current  version  of 
NLS,  a  link  nay  point  only  to  statement  entities. 

With  greater  resolutio.  for  link  references,  for 
instance,  a  link  may  ce  constructed  to  refer 
specifically  to  another  link.  This  is  the  basis  for 
indirect  linking,  to  oe  discussed  below, 

b.  Possible  Syntax  for  New  NLS  Link  Entity 

<TYPEiDATE,TI*E>  ( USERNAME,  FILENAME, 

7.  OCENTITY*  VIEW  SPECS) 


TYPE  is  any  number  of  descriptor  mnemonics  defining  the 
type  of  the  link.  Facn  descriptor  would  oe  delimited  by 
a  comma. 


MMDDYY  HKHH i S3  is  the  date  and  time  the  link  was  created, 
cr  the  date  and  time  tne  link  was  last  "stamped,"  in  the 
format  <montft,  day,  year,  nour,  second). 

At  any  time,  the  link's  owner  may  initialize  the  time 
and  date  for  tne  link,  using  a  date-tide  "stamping* 
command, 

USERNAME,  FILENAME,  and  VIEWSPEC  have  the  same  meaning  as 
in  current  NLS  links. 
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LOCENTITY  identifies  a  specific  target  entity. 

Detailed  syntax  for  the  LOCENTITY  nay  oe  arbitrarily 
complex.  The  following  example  indicates  a  simple 
statement-number  syntax. 

c.  Example 

<commjUrf,Evanej09/17/69  001U  U  ia> 

( in fel Part, plans, m- Pi xi) 

TYPE  is  "comm,ur2,Evanr" 

DATE, TIME  is  "09/17/69  OOUiU" 

USEPNAME  is  "Engelbart" 

FILENAME  is  "plans'* 

LOCENTITY  is  "m-pM  (the  marker  "?") 

VIE ’/SPECS  are  xi,  meaning  display  only  one  line  of 
top-lsvel  statements,  and  switch  on  the  content 
analyzer. 

This  link  refers  to  the  entity  with  marker  "PH  affixed 
("m-P")  in  the  file  "iplans"  owned  oy  user  name 
"Engelbart. "  It  points  from  a  comment  (“comm")  that  is 
urgent  Pure")#  and  should  be  brought  to  the  attention  of 
user  name  "Evans,"  The  link  was  last  stamped  09/17/69  at 

oenut. 

3.  New  VIEWSPECs  for  Links 

Increased  link  complexity  demands  more  powerful  viewspecs  to 
simplify  displaying  the  link  construct,  so  links  do  not  make 
the  remainder  of  the  text  illegible. 

Additional  YIIWSFIC3  will  be  available  for  totally  or 
partially  suppressing  display  of  tne  link  construct,  Fo^ 
instance,  the  user  could  control  which  fields  in  the  link 
were  displayed  at  the  link's  location  in  a  statement  (this 
VIEW3PEC  would  apply  to  the  entire  display).  If  the  link 
was  to  be  totally  nuppressed,  an  additional  vlt/SPEC  would 
allow  the  user  to  control  whether  or  not  special  H  iln* 
markers"  were  displayed  at  the  link's  normal  location, 

A  user  would  interrogate  an  individual  link  marker,  to 
display  the  particular  link  represented  by  that  marker, 
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vithout  displaying  all  links, 

k.  Links  Not,  imbedded  Directly  in  Text 

Because  of  the  "stationary  target"  concent  and  tne  freavent 
need  to  attach  linxs  to  existing  Journal  entries,  it  will  oe 
necessary  to  nave  a  new  NLS  command  to  enable  a  user  to 
associate  an  NiS  link  witn  any  selected  text  entity,  but 
have  that  linn  displayed  only  as  an  overlay  tc  tne  file, 
ratr.er  than  an  integral  part  of  tne  normal  text.  Link 
markers,  similar  to  those  used  for  backlinking,  will  oe  used 
to  indicate  tne  presence  of  one  of  these  links.  New  NL3 
commands  will  be  available  to  enable  tne  user  to  control  tne 
display  of  the  link  and  markers* 

5.  Indirect  Linking 

Once  it  is  possible  to  "aim"  a  link  at  any  arbitrary  entity, 
suen  as  anotner  link,  or  at  a  simple  character  In  a 
statement,  indirect  linking  becomes  possible.  Tne  following 
example  illustrates  detailed  operation  for  indirect  linking. 

Exanple:  The  following  link  is  displayed  in  a  statement 
of  the  file  (Evans, ddd)  ;  <comn; >( Engelbart., plans, n-P :) . 
Note  tnat  the  date^time  field  nas  been  suppressed  by  the 
new  link  VIEkSPECS  described  previously.  This  link  is 
embedded  m  a  statement  (or  oranen}  constituting  a 
comment  on  its  DIRECT  tareet. 

In  the  file  (Engelbart, plans)  there  Is  a  marker  "P" 
affixed  to  a  character  Just  preceding  another  link,  as 
followsi  <P>xx  yyy  cc  <comm;> (Evans, rrr,12biw) ,  This 
link  is  a  comment  on  12b  in,  the  file  > Evans,  trrr) . 

Use  of  the  new  command  JUMP  INDIRECT  LINK,  with  the 
original  link  as  operand,  causes  the  statement  12b  to  oe 
displayed  under  the  control  of  VIEW3PEC  "w"  (all  lir.es  of 
all  statements) . 

6,  Backltnka 

The  most  important  additions  to  existing  NLS  linking 
features  for  use  in  the  DBS  are  the  bacxlink  operations. 

Backlinking  means  that  a  special  executable  link  marker  is 
deposited  in  the  referent  being  pointed  at  by  a  link.  This 
enables  a  user,  viewing  the  referent  entity,  to  "JUMP 
3ACKLINX'’  and  display  the  entity  containing  the  original 


170 


Appendix  B 

THE  DSS  AND  THE  JOURNAL 


link. 

Trie  existence  cf  an  MS  link  reference  to  any  displayed  NLS 
entity  will  be  indicated  oy  special  bicKUnk  narNera. 

Display  of  these  markers  will  dc  under  user  control  in  a 
manner  similar  to  link  markers,  described  previously. 

A  user  may  interrogate  a  backllnk  marker,  to  nave  data  on 
the  source  entity  displayed.  Execution  of  tne  new  command 
JUMP  BACKLIh K  with  a  backlir.k  marker  as  operand  displays  tre 
source  entity  at  the  top  of  the  display. 

Indirect  backiinking  will  also  be  available,  indirect 
backlin k  Jumping  means  tnat  a  user  executes  JUMP  BACKLINK 
INDIRECT,  and  the  system  displays  tne  statement  containing 
the  link  that  points  at  the  source  of  the  backlink  marker 
entered  as  the  operand  for  this  commana. 

7.  Remote  Linking 

The  basic  concept  for  remote  linkinr  is  that  of  attaching 
the  "head"  of  a  link  to  its  referent  entity,  followed  by 
insertion  of  the  link  itself  in  tne  source  entity,  rerote 
from  the  referent,  at  some  late*  time. 

This  may  be  accomplished  by  the  following  steps: 

(1)  Assigning  a  temoora  '  marker  to  yet  anotner  entity, 
"link  referent" 

(2)  Depositing  that  marker  at  the  apnropriate  location 
in  the  referent  statement 

(3)  Later,  while  inserting  the  basic  link  construct  in 
tne  source  statement,  calling  for  tne  referent  entity 
data  to  be  inserted  in  the  link  by  using  a  special  INSERT 
RIFIRENT  DATA  command,  entering  the  referent  marker  as 
operand. 

This  type  of  operation  depends  upon  each  user  having  at 
least  two  NLS  flies  open  simultaneously.  If  links  and 
backlink*  are  considered  to  be  completely  symmetrical,  this 
procedure  may  be  used  interchangeably  with  tne  conventional 
INSiRT  LINK  command. 
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C.  Copying  a  Journal  Entry 

A  problem  arises  when  a  Journal  entry,  stored  as  a  colon  file, 
is  copied  to  a  new  filename.  All  backlir.K  narxers  are 
retained,  out  the  links  generating  tnese  markers  continue  to 
refer  to  the  original  journal  entry,  and  ao  not  point  at  the 
new  file.  Thus  an  additional  type  of  bacxlink  is  produced  -- 
one  that  has  no  forward-pointing  linx  associated  with  it. 

These  asymmetrical  oacklink  markers  maxe  it  possiole  to  .lump 
to  files  and  entries  that  referred  to  the  original  entry. 
They  may  be  deleted  if  judged  to  ce  inappropriate  for  the 
new  file. 

At  the  time  the  new  file  is  created,  the  system  will 
automatically  insert  a  link  in  the  file's  header  statement, 
pointing  at  the  header  statement  in  the  Journal  entry  from 
which  it  has  been  copied,  and  depositing  a  backlink  marker  in 
the  header  of  the  journal  entry. 

D.  Ordered  Set* 

A  set  is  a  special  new  NLS  entity  --  It  is  a  collection  of 
other  entities  (e.g.,  of  characters,  files,  statements,  links, 
other  sets,  etc.).  The  design  and  implementation  of  operations 
associated  with  sets  is  a  complex  proolem.  The  following 
indicates  what  seem  to  be  the  most  promising  possibilities. 

An  "ordered"  set  has  *  specified  order  associated  w ivn  its 
member  entities.  Sets  are  given  unique  names  for 
identification.  For  convenience,  a  set  U311  be  attached  to  a 
"parent"  file,  selected  arbitrarily  by  the  user.  /’Evans, xxxy 

is  the  set  named  "XXX"  owned  by  the  user  name  "Evans."  Set 
names  are  similar  to  statement  names,  except  they  must  be 
unique  over  the  entire  universe  of  a  user's  files  --  it  is  not 
possible  to  have  a  set  named  "XXX*  associated  with  the  file 
tccc  and  another  set  "XXXK  associated  with  the  file  :ddd,  if 
both  i ccc  a,.d  iddd  are  owned  by  the  same  user.  However, 
different  users  may  own  seta  with  the  same  name. 

1,  Admission  to  a  Set 

Other  NLS  entities,  including  other  sets,  way  be  "admitted" 
to  a  set,  using  the  command  "ADMIT  <entity>  10  3r,T 
<setr ameV* ,  and  entering  the  appropriate  operands. 

"Jntity"  is  the  NLS  entity  selected  or  specified  by  the 
user;  "setname"  is  the  name  of  an  existing  set  --  the  set 
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to  which  the  entity  1a  to  pe  aarutted. 

Not  only  entities,  put  specific  views  and  specific  subsets 
of  entities,  nay  Pe  admitted  to  a  set. 

Example!  The  first  line  of  the  first  two  levels  of 
statements  in  a  file  satisfying  a  given  content  pattern, 
nay  Pe  admitted  to  a  set.  The  remainder  of  that  file, 
unless  specifically  admitted  on  anotner  occasion,  does 
not  belong  to  tne  set. 

2.  Direct  and  indirect  use  of  Sets 

There  are  three  modes  for  using  sets:  "normal, "direct," 
and  "indirect." 

■Normal"  mode  corresponds  to  normal  NLS  usaire  in  which  the 
set  entity  has  the  same  status  as  normal  NLS  entities 
(words,  characters,  etc.). 

Thus  in  normal  mode*  the  command  DELETE  SET  erases  the 
set  whose  name  is  riven  as  an  operand.  Note  that  the  set 
is  erased^  not  the  members  of  the  set. 

In  "direct"  mode,  operations  performed  on  a  set  produce 
changes  in  the  actual  entities  admitted  to  the  set. 

Example!  A  (hypothetical)  command  "DELETE  WORD  m-soec  IN 
SET  Levans, X] n  la  entered;  "spec"  is  an  NLS  marxer  name. 
Upon  execution,  in  direct  mode,  all  words  so  marked  in 
the  entities  that  are  members  of  the  set  /revans,x7  will 
actually  Pe  deleted.  That  is,  they  will  pe  deleted  in 
the  same  sense  as  if  tne  user  displayed  each  entity  in 
the  set  containing  the  marker,  and  manually  deleted  the 
marked  word,  followed  oy  the  command  OUTPUT  FILE. 

Entities  changed  through  operations  performed  on  sets  in 
"direct"  mode  remain  changed  after  the  system  is  returned 
to  "normal"  mode. 

In  "indirect"  mode,  operations  performed  on  entities  that 
are  mwmper#  v-2  a  set  (py  using  the  *et  name  itoelf  is  the 
operand)  produce  changes  in  those  entities  ONLY  while  the 
user  views  them  "through"  the  set. 

For  instance,  if  in  tne  previous  example  the  sane 
operation  was  performed  in  "indirect"  node,  the  narked 
words  would  not  pe  deleted  in  the  files  containing  tne 
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marked  entities  m  question,  but  would  only  "appear"  to 
be  deleted  wnen  the  viewer  was  working  with  the  set 
fevahs, xy  controlling  the  entities  he  could  display. 

This  appearance  would  oe  negated  as  soon  as  tne  user 
returned  to  display  any  member-file  in  normal  mode, 

3.  Open  and  closed  Sets 

a,  Closeo  Sets 

a  closed  set  is  one  wnose  membership  i«  specified 
explicitly,  l.e.,  there  is  a  finite  fully  aeternmed 
membership  list  associated  witn  the  set.  for  example, 
statement  entities  might  be  specified  by  a  list  of  nls 
links.  There  are  three  types  of  closed  sets;  frozen, 
unfrozen,  ana  nixed. 

A  frozen  closed  set  retains  the  exact  content  and 
structure  of  each  entit;  ,  in  the  state  in  which  it  was 
originally  admitted  to  1  ne  set.  Even  if  (say)  a 
member  statment  is  aeleted,  a  "copy"  is  retained  in 
the  set- 

An  unfrozen  closed  set  retains  a  finite  membership, 
but  permits  each  member  entity  to  adopt  its  latest 
actual  state,  for  example,  a  whole  file,  containing 
three  statements  admitted  tc  an  unfrozen  closed  set  on 
day  1,  subsequently  undergoes  major  modif ications .  If 
the  set  is  used  as  an  operand  on  day  3  'after  the 
modifications),  the  file's  state  at  that  time  is  uced. 

A  mixed  set  contains  entities  whose  f rozen/unf rezen 
status  is  determined  individually.  In  other  words,  a 
set  may  contain  some  entities  whose  original  status  is 
retained,  and  some  whose  status  is  the  latest  status 
of  the  entity  itself. 

b.  Open  Sets 

An  open  set  is  one  whose  membership  is  not  fixed  by 
explicit  identification  of  its  member  entities,  cut 
rather  by  the  specification  of  conditions  to  *e  met  to 
admit  member  entities. 

for  example,  tr.  open  set's  membership  may  be  ‘mined 
by  those  statements  in  a  given  file  universe  satisfy 

a  given  content  pattern. 
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On  day  1,  this  nay  yield  a  dif'  'ent  membership  than  on 
day  L,  if  modifications  were  mac*  to  files  in  that 
universe  during  this  period. 

L,  Set  Operations 

There  *,re  two  major  and  distinct  classes  of  operations 
associated  with  sets  •  »  operations  on  sets,  and  operations 
within  sets.  The  distinctions  between  these  classes  are 
important. 

a.  operations  on  Sets 

operations  on  seta  use  entire  sets  as  operands. 

3imple  Operations  on  Sets 

These  operations  include  the  star  dard  NLS  operands  -- 
INLERT,  DELETE,  REPLACE,  etc.,  in  addition  to  a  new 
clasp  of  commands  --  sec-theoretic  operations. 

INSERT  3ET  creates  a  new  s^t. 

REPLACE  SET  makes  it  possible  for  a  user  to  make  a 
r.sw  set  as  the  union  of  one  or  mere  existing  seta, 
and  to  simultaneously  delete  the  original  sets 
(their  names,  not  members), 

DELETE  SET  erase.*  the  set  (but  not  its  members), 

Set-Theoretic  Operations  on  seta 

There  will  be  new  NL3  commands  to  enable  a  user  to 
perform  set-theoretic  operations  on  sets.  The 
following  set-theoretic  commands  will  ce  available: 
UNION,  INTERSECTION,  COMPLEMENT,  and  DIFFERENCE ,  where 
each  operation  has  its  usual  mathematical  meaning. 

b.  Operations  Within  Sets 

Operations  within  sets  have  entirely  different  meanings 
from  operations  on  sets,  and  fron  operations  on  member 
entities  outside  the  influence  of  the  set  construct. 

When  under  the  control  of  operations  within  sets,  the 
conventional  HLS  commands  take  on  the  following  meaning: 

MOVE:  Change  the  ORDER  of  member  entities  in  the  set. 
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DELETE:  Remove  the  operand-entity  fr-  memoership  of 

the  set. 

COPY:  Include  the  operand-entity  once  more  in  the  set 
memoership  (in  a  dufere^t  position  vitnm  the  set's 
order)  . 

INSERT:  Admit  tr.e  operand-entity  to  membership  in  the 

set. 


REPLACE:  Reolace  the  member  entity  selected  as  operand 
with  the  entity  selected.  The  entity  selected  as  a 
replacement  nay  or  ruy  not  oe  a  member  oi  the  set. 

E.  Executable  Statements 

An  executable  statement  will  be  a  new  text  construct,  using  the 
current  NLS  statement  as  a  basis.  NLS  commands  will  oe 
pre- specified  as  a  tent  string  in  an  executable  statement. 

They  will  be  executed  by  using  tne  command  EXECUTE  STATEMENT, 
giving  the  statement  numner  of  tne  statement  as  operand. 

An  executable  statement  *»ill  be  the  means  to  effect  conoound  cr 
concatenated  operations,  including  set  operations,  The 
structure  and  meaning  of  the  executable  statement  features  c*r. 
beat  be  Illustrated  by  examples. 

Example:  The  following  is  an  executable  statement, 

(XXX)  (£vafi3,3ss,i2 :x)  ( tngelbar t , plans , 2 i w)  e  c  ca 

/■"retrieve  "j  OR  /'"Retrieve"/  ;  CA  (evans, rrr, : wi >  end 

(1)  by  activating  tr.e  command  EXECUTE  STATEMENT,  and 
entering  the  operand  "XXX"  (the  name  of  the  executable 
statement),  followed  by  a  single  CA,  tne  first  lin* 
will  oe  executed  as  if  JUMP  FILE  LINK  was  used  with 
that  linx  as  its  operand. 

(2)  The  user  views  the  file  (evans,«ss)  with  statement 
12  a t  the  top  of  tne  sere  i,  displaying  only  the  first 
lines  of  suosequent  top-i.vel  statement!?  lr  tne  file, 

(3)  A  second  CA  causes  tr.e  second  iinx  to  oe  executed. 

U)  The  user  views  the  file  ( engelbart,  plans )  ,  with 
statement  2  at  the  top  of  the  screen,  displaying  all 
lines  of  all  statements. 
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(5)  A  third  CA  causes  the  content  Dattern  /retrieve; 
OR  [m Retrieve"/  to  he  compiled,  automatic  illy  followed 
by  the  execution  of  the  last  link.  Note  that  the 
VXEWSpSC  "i"  in  the  last  link  activates  the  pattern. 

(6)  The'result  is  that  the  file  (Evans, rrr)  is 
searched]  all  statements  containing  the  text  construct 
“retrieve11  or  “Retrieve”  are  displayed. 

Example:  The  following  executable  statement  illustrates 
more  complex  operations  on  sets. 

(YYY)  [DOD]  •  /ARMY/  UNION  /NAVY/  ;  /USA/  »  [DOT)] 
INTERSECTION  /'MIC/  ;E  C  CA  /beacon";  j  CA 
(Nixon, /USA/ , jwi)  CA  DISPLAY : w  OUTPUT  TIlE  *:arsenal' 
DELETE  SET  /jjOD/  AND  SET  /USA/  END 

(1)  The  command  EXECUTE  STATEMENT  is  executed  with  the 
operand  YYY ,  the  name  of  the  statement. 

(2)  A  CA  causes  a  new  set  "DOT"  to  be  formed  as  the 
union  of  the  two  existing  sets  "army  and  "navy."  This 
set  will  be  attached  to  the  file  containing  tne 
executable  statement. 

(3)  Another  CA  causes  a  second  set,  "USA"  to  oe  formed 
as  the  intersection  of  the  two  sets  "D0DM  and  "MIC," 

(S)  Another  CA  causes  tne  content  pi ttern  "weapon”  to 
be  compiled,  immediately  f  ilowed  b>  execution  of  the 
link  transferring  control  to  the  first  entity 
containing  the  tsxt  construct  "weapon”  in  the  set 
*’U3AM  (which  is  owned  by  the  user  "Nixon"). 

(5)  The  system  searches  all  entities  in  this  set,  and 
displays,  under  Vie*sfec  contol  "w"  (all  lines  of  all 
statements)  those  statements  containing  tne  text 
string  "weapon". 

(6)  A  final  CA  causes  this  collection  of  entities  tc 
be  output  as  the  new  file  '{arsenal,1  Another  CA 
causes  both  the  seta  (as  distinct  from  tne  set 
membership)  /USA/  and  /DOD/  to  be  deleted. 

Example*  The  following  ex?‘»utcble  statement  illustrates  how 
the  member  entities  of  a  set  may  be  displayed, 

lZZZ)  PI S PLA x  I  w  /HEREANDNO */  7ND 
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By  giving  tne  command  EXECUTE  STATEMENT  witn  III  as  the 
operand,  followed  oy  a  CA,  all  entitle*  in  the  set 
" H E R E A N D N 0 W will  oe  displayed,  under  VIE^SPEC  control 
:'w"  (all  lines  of  ail  statements). 

Example:  The  following  is  an  example  of  sir.Dle  "chain 
generation"  using  an  executaole  statement, 

(AAA)  dARKLP,  =  A1  CHAli>  { e  van  s ,  as ,  12  ;  g  w )  ( e  vans ,  ss ,  5  :  ew 
(Er.gelbart,  plans ,  f :  wn)  END 

By  giving  tne  command  t-XECUTE  STATEMENT  witn  the  ocerar.d 
"AAA",  followed  by  a  Ca,  the  display  starts  with  an 
ail-all  view  of  the  bran.cn  starting  uith  statement  12  in 
(Evans, :ss) .  Normal  text  operations  may  oe  performed  on 
this  branch.  If  a  second  marker  A1  is  entered,  the 
all-all  view  of  the  branch  starting  with  statement  5  in 
(evans,:ss)  is  displayed,  and  so  on. 

Here  a  marker  is  used  as  the  means  to  advance  the  view 
along  the  chain.  This  permits  normal  text  ooerations 
(requiring  CA's)  to  oe  performed  at  each  view  along  the 
chain. 

In  all  examples,  the  maximum  VIErfSPEC  operative  on  any 
entity  is  controlled  'ey  the  VIEWSP^C  assigned  to  the  set 
member  entity  itself  at  the  time  it  was  admitted  to  the  set, 

F.  Miry  Descriptors 

Descriptors  will  be  tacned  directly  to  journal  entries, 
either  at  tine  of  ei  j  to  the  Journal,  or  at  some  later  date. 
TL-se  descriptors  will  cover  at  least  the  following  classes: 

(1)  Subject  natter/tvpe  of  entry 

Examples;  comment;  messages  announcement;  injunction 

(2)  Urgency 

Examples!  urgent;  r.ct  urgent 

(3)  Names  of  use^s  those  attention  is  sought 
Example:  attention;  evans,  engelbart. 

U)  Authc;-/  source  of  entry 
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Example:  autnor:  evans; 

(5)  bate/tire  of  entry  tc  journal 
Example*  entered  9/26/69  1006:30 
0.  interrogation 

Oommanda  win  be  available  to  enable  a  user  to  interrogate  a 
Journal  entry  in  order  to  a ak  the  following  tvpea  of  questions: 

(a)  Which  Journal  entries  cr  other  files  are  pointing  at  tne 
interrogated  entry? 

(p)  To  which  sets  does  the  interrogated  entry  oelong? 

When  interrogating  to  determine  which  entries  cr  other  filjs 
are  pointing  at  the  entry,  tne  user  will  oe  able  to  control  the 
universe  ever  wnich  the  search  for  these  entries  is  to  Pe 
performed. 

For  instance,  the  user  may  ask  for  only  those  entries  that 
point  at  the  interrogated  entry,  or  are  attacned  oy  links  of  a 
specified  type,  from  entries  of  another  specified  type,  that 
were  made  after  a  speefied  date. 

Example:  Display  Journal  entries  of  type  "comment"  or 
"injunction"  that  are  attached  with  link  types  "urgent"  made 
after  8/12/69  to  Journal  entry  Humber  XXXXX. 

Example:  Display  thotfe  members  of  the  set  fevans.xxx;  admitted 
to  the  set  after  10/1/69. 

H.  Miscellaneous  New  NtS  Features 

Numerous  new  NIS  features  will  have  a  major  effect  on  the 
usefulness  of  the  DSS ,  although  they  are  not  designed 
exclusively  for  DSS  usage.  These  features  include  split 
screens,  file  merging;  new  VIEWSPECS,  *nd  "file  history." 

1.  Split  Screen 

The  "split  screen"  feature  generalizes  characteristics 
of  the  "freezing"  option  in  the  current  version  of  nls. 
with  a  split  screen,  the  user  is  able  to  display  two 
different  views  of  the  same  file,  or  two  different  and 
independent  views  of  any  two  files,  one  on  each  side  of  the 
screen.  He  will  be  able  tc  work  with  the  displayed 
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information  in  each  "window"  as  if  it  was  a  separate  and 
independent  file.  The  success  of  this  option  depends  upon 
bavin*  more  than  one  file  open  for  a  given  user  at  any  riven 
time.  The  split  screen  will  make  interfile  editing,  and 
more  complex  file  merging,  easy  and  useful. 

2,  File  Merging 

The  split  screen  and  other  new  features  make  tne  capacilitv 
for  merging  any  two  files  to  form  a  third  composite  file  a 
necessity.  In  the  current  version  of  NLS ,  only  the  simplest 
file  merging  operation  --  appending  --  is  possinle.  more 
useful  file  merging  would  include  the  facility  to  interleave 
statements  in  a  specified  order,  and  to  transfer  pictures 
from  one  file  to  another. 

3.  File  History 

Keeping  tracK  of  a  file's  nistory  Decones  more  important  in 
the  Journal  and  DSS  than  in  current  NLS  operations.  For 
this  reason  a  new  NLS  feature  will  be  added  to  capture  all 
necessary  identification  information  from  the  source  file 
every  time  a  file  is  output  or  copied.  Thio  information  nay 
be  copied  directly  from  the  header  statement  of  the  source 
file,  and  written  into  the  header  statement  of  the  object 
file  at  the  time  it  is  created. 

Example:  The  following  is  an  example  of  a  standard  file 
header, 

JXVIII,  9/26/69  120*  s  30  DaE; 

Here  :XVIII  is  the  filename;  9/2o/S?  120913c  is  tne 
date  and  time  the  file  was  last  output  to  the  name 
:XVIII,  and  DaE  are  tne  initials  of  the  file  owner. 

Suppose  tne  file  rXVIII  ie  output  to  tne  new  file  name 
":CHAPi8rt. 

After  the  operation  is  completed,  the  header  of  the 
object  file  (:CHA?lo)  reads  as  follows: 

iCHAPlft,  9/26/69  1211: u*  DAE;  ( e vans , X VI I 1 , : ) 

9/26/69  1211145; 

The  system  has  rewritten  the  source  file's  header  data 
as  an  Nl,5  link  following  tne  object  file's 
conventional  header  data.  Note  that  as  later  versions 
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of  tCHAPlc  Are  made,  data  preceding  the  first 
semicolon  changes.  witn  subsequent  coov  operations, 
or  output  file  operations  to  new  filenames,  cnese  data 
from  the  file  jXVIII  will  be  retained  in  tr.e  new 
file's  header,  along  witn  all  records  of  subsequent 
operations . 

I.  Cataloguing 

A  catalogue  of  all  entries  in  the  Journal  will  oe  maintained, 
providing  the  main  conventional  aid  for  retrieval  of  these 
files.  The  catalogue  will  have  three  main  sections!  a  subject 
index,  a  Keyword  list,  and  citations  for  Journal  entries. 

The  subject  index  contains  a  hierarchical  structure  of  tne 
subjects  describing  Journal  entries,  with  their  respective 
Keywords  attacned.  A  user  nay  scan  this  index  and  select 
Keywords  attached  to  the  subjects  that  neet  nis  needs^ 

Tht  Keyword  List  will  contain  Keywords  {as  used  in  the 
subject,  index),  followed  py  linKs  pointing  at  appropriate 
citations. 

The  citation  for  each  Journal  entry  is  stored  m  tne 
catalogue  by  order  oz  Journal  Entry  Number.  Each  citation 
will  constitute  an  NLS  branch,  with  the  Journal  Entrv 
Humber,  and  link  to  tne  cited  Journal  entry,  as  the 
first-level  statement  of  each  branch. 

Each  such  citation  branch  will  contain  the  entry  number., 
the  source  filename,  the  name  of  the  user  submitting  the 
entry,  the  date  and  time  when  the  entry  was  submitted, 
and  a  list  of  descriptors  for  entry. 

These  data  will  be  stored  in  a  manner  that  manes  them 
useful  for  further  NLS  operations,  for  example,  the 
data  on  source  filename  is  stored  in  tne  form  of  z 
conventional  KLS  linn  referring  to  the  source  file. 
Similarly,  eacn  catalogue  entry  contains  a  link  to  tne 
Journal  entry  itself, 

1,  Retrieval  System  Based  on  the  journal  Catalogue 

The  existing  NLS  Keyword  retrieval  system  will  oe  extendea 
for  use  as  the  basic  retrieval  tool  for  operations  on  the 
catalogue.  The  major  drawback  of  the  current  system  is  that 
lists  of  citations  can  be  assembled  only  from  within  a 
single  file, 
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For  tne  OSS ,  this  system  will  be  modified  to  operate  across 
an  arbitrary  number  of  files.  Suer,  operations,  of  course, 
depend  upon  otner  features  discussed  previously  file 

merging,  tne  capability  of  bavin*  nore  tnan  one  file  op-n  at 
any  instant ,  etc . ) . 

The  standard  Keyword  statement,  which  currently  uses 
statement  names  as  keyword  arguments,  will  be  changed  to  use 
full  N’L3  links  as  keyword  arguments. 

Example ; 

(Keyj)  This  is  Keyword  three  *  ( JOUxNA*.,  131J99 ,  i  ) 
(Journal, lu6j$9 , : ) 

The  user  will  then  have  tne  following  options; 

(1!  Assemble  the  citations  derived  from  a  selection  of 
keywords  from  one  or  more  files  (which  may  themselves  oe 
stored  in  several  catalogue  files),  as  a  list  in  one 
file,  and  use  the  standard  jump  LINK  command  to  view  tne 
actual  Journal  entries  cited,  one  by  one. 

(2)  ask  for  consecutive  display  of  tr.e  actual  Journal 
entries  citea,  under  the  control  of  the  VIErfSPECS  in  tne 
keyword  referent  links.  Consecutive  entries  cited  would 
pe  displayed  as  if  part  of  the  same  file. 

This  operation  could  be  accomplished  oy  special  new 
NLS  machinery,  or  by  concming  tne  capabilities  of 
executable  statements  and  indirect  linking, 

Ir.  all  cases,  all  current  NLS  keyword  options,  including  tne 
allocation  of  weights  to  Keywords,  will  oe  available. 
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I  Introduction 

This  appendix  is  an  addendum  to  the  previous  Hardware  Reference 
Manual,  Appendix  b  of  Ref.  3,  It  consists  of  a  programmer's 
reference  manual  for  the  following  equipment; 

A  line  printer  (replacing  the  line-printer  description 
contained  in  the  previou*  manual.) 

Ar.  inter-core  controller  for  transfers  between  RuO  core  and 
external  core  ("Xcore") 

A  Network  interface  connecting  the  9L0  to  the  arpa  Network  via 
the  Interface  message  Processor  (IMP) 

A  precision  clock, 

II  Line  Printer 

A,  General  Information 

The  printer  id  a  Data  Prc--wta  Model  M600-11A  with  96 
characters  and  a  printing  speed  of  aoout  3L0  lines  rer  minute. 
It  will  accomodate  paper  from  2-1/2  to  16-1/2  inche  in  width. 
Character  spacing  is  10  per  inch  and  line  spacing  is  fc  per 
inch.  The  maximum  nunher  of  characters  per  line  is  132. 

The  printer  is  controlled  by  eom  instructions  and  a  "unit 
reference  cell"  (URC).  The  URC  points  to  &  print  Duffer 
resident  in  core  that  contains  data  and  control  codes.  An  5KS 
instruction  indicates  "printer  ready''  and  an  interrupt 
indicates  "end  of  operation,"  either  normal  or  error.  Error 
conditions  are  detected  by  the  controller  and  an  error  code 
written  in  the  URC . 

The  cells  immediately  following  the  URC  In  core  are  called 
"URC*1,M  "URC* 2, "  etc. 

Fixed  core  assignments  for  the  printer  aret 

URC  10 

Interrupt  211. 

9.  EOM  and  SKS  codes 

The  EOM  codes  are; 

20230106  Initiate 

20230U06  Reset. 


163 


X  o 


E  MANUAL  TOR  PERIPHERAL  EQUIPMENT 


The  "initiate"  EOM  starts  the  printer  with  tne  word  and 
character  designated  by  tne  contents  oi  tne  URC  at  the  tine 
the  EOM  is  given. 

The  printer  controller  continues  to  process  tne  printer 
puffer  until  an  illegal  cnaracter  or  end-ol-buf ier  cone 
is  read,  or  until  a  "reset'*  EOr.  is  issued. 

An  "initiate"  EOM  Riven  wnile  the  printer  is  pusy  is 
ignored. 

The  "reset"  EOn  immediately  terminates  all  printing  and 
returns  tne  system  to  a  reset  state. 

A  "reset"  EOh  given  while  tne  printer  is  disconnected  ia 
ignored . 

One  SKS  code  i«  provided  for  the  printer .  Tne  cede  is 
0E030106  Skip  on  ready. 

This  SKS  PKips  if  the  printer  is  ready  to  begin  operation. 
If  tne  printer  is  not  ready,  an  interrupt  is  issued  when  it 
i*  made  ready. 

C,  unit  Reference  Cell 

The  URC  associated  with  the  printer  system  nas  the  following 
format : 

0  3  •>  d  2  3 


l  ! 


error  address 

Bits  6-23  contain  the  absolute  address  of  the  first 
character  cf  the  line  to  oe  printed  lor  currently  oeing 
printed) . 

bits  6-23  denote  the  absolute  word  address. 

Sits  6-7  indicate  the  character  in  the  word. 

k  00  code  is  the  leftmost  character.  The  11  code  is 
not  used  but  is  interpreted  as  the  leftmost  cnar&cter. 

After  a  line  has  been  successfully  printed,  th_  address 
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in  the  URC  is  updated  to  po  „t  to  the  first  cnaracter  of 
the  next  line. 

Bits  0-3  are  written  py  the  controller  with  an  error  code 
when  errors  are  detected-  Error  conditions  ana  codes  are 
described  below. 

Bits  lt-5  are  ignored  by  the  controller, 

D.  Print  Buffer 

Tne  print  cuffer  is  a  contiguous  sequence  of  words  in  core  that 
is  interpreted  by  the  prince;-  controller  as  three  6-bit 
characters  per  word. 

Characters  in  the  print  buffer  may  be  either  data  characters  or 
control  characters. 

The  control  characters  are: 


373 

(NOP) 

No  operation 

375 

(EOB) 

End  of  print 

buffe.- 

376 

(EOL) 

End  of  line 

377 

(NOP) 

No  operation 

01 5 

Shift 

to  lower  case 

and 

lock 

035 

Shift 

to  lower  case 

for 

one  character 

055 

Shift 

to  upper  case 

and 

lock. 

An  ECL  or  EOB  code  causes  the  current  line  to  be  printed 
with  any  characters  already  in  tne  line  left- Justified . 

An  EOB  code  generates  an  interrupt  to  the  computer  after 
the  line  is  printed  ar.d  any  spacing  action  has  been 
completed , 

Tne  three  case-shift  codes  are  self-explanatory.  They 
can  appear  4nywhere  within  a  line  of  data  characters  and 
cause  the  indicated  c&se-snift  actions. 

in  addition  to  the  explicit  control  characters,  the  first 
character  in  each  line  is  Interpreted  as  a  paper-feed  code. 
These  codes  are  as  follows  (the  word  "space"  here  refers  to 
line  spacing,  not  the  "space"  character) i 

020  Space  1  line 

021  Space  1  line 

022  Space  2  lines 

023  Space  3  lines 
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02k 

Space 

k 

lines 

025 

Space 

S 

lines 

026 

Space 

6 

linei 

027 

Space 

7 

lines 

000 

Space 

on 

channel 

0 

of 

format 

cape 

001 

Space 

on 

channel 

1 

of 

format 

tape 

0C2 

Space 

on 

chann.l 

2 

of 

format 

tape 

003 

Space 

on 

channel 

3 

of 

format 

tape 

COE 

Space 

on 

channel 

u 

of 

format 

tape 

005 

Space 

on 

channel 

3 

of 

format 

tape 

006 

Space 

on 

channel 

6 

of 

format 

tape 

007 

Space 

on 

channel 

7 

01 

format 

tape 

Tne  action  indicated  by  the  space  code  taxes  place  before 
tne  line  is  printed. 

Two  successive  spacing  operations  can  be  caused  by 
sending  one  of  the  above  space  codes  followed  c.v  "end  of 
line"  (376),  then  another  code. 

If  no  spacing  is  desired,  as  wnen  printing  the  top  line 
on  a  page,  a  no-op  code  (377)  snoula  be  sent  in  tne  first 
position  of  that  line. 

Cnan.nel  1  of  the  format  tape  is  used  for  "top  of  form." 
The  number  of  lines  on  a  page  is  normally  set  to  ow, 

Except  for  the  first  char.cter,  tne  print  Duffer  contains 
only  printing  characters  (including  space  characters)  and 
control  characters.  Any  other  character  codes  in  the  print 
buffer  are  considered  illegal  an"'  cause  an  error  condition, 

Print  buffers  may  be  as  large  as  dt  ed,  tut  no  relocation 
napping  is  provided.  If  a  buffer  is  to  extend  across  a  page 
boundary,  the  software  system  must  ensure  that  the  two  pages 
are  consecutive  in  memory. 

E.  Error  Conditions 

On  the  detection  of  any  error,  ar  interrupt  is  issued  and  the 
error  code  is  written  in  the  URC. 

The  error  cedes  and  conditions  detected  arei 

QUO  No  error 

101  Illegal  character  cede 

110  Printer  not  ready 

111  Excessive  time. 
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Zero*  in  the  error*code  Pit*  of  the  URC  after  an  interrupt 
indicate  a  normal  interrupt  (printer  made  ready  or  EOB). 

The  101  cud*  indicate*  that  an  illegal  cnaracter  has  been 
detected  in  the  print  buffer. 

Tilt  110  code  indicates  printer  off-line,  paper  outr  or 
ribbon  failure. 

The  .ill  code  indicate*  tnat  in  a  normal  orintini  operation, 
exceptive  time  ha*  been  required  for  printing  a  line. 

The  timer  ia  normally  set  for  2.5  seconds,  inis  error 
indicates  printer  failures  not  detected  by  other  printer 
error  circuits. 
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F.  Character  Codes 


The  printer 

character 

coaes 

are  «iven  below. 

The  case 

:  printed 

is  determined  by  the 

shift- 

control  character. 

CODE 

UPPER 

LOWER 

CODE 

UPPER 

lower 

000 

0 

01*0 

m 

underbar 

001 

1 

0U1 

J 

j 

002 

2 

0U2 

K 

k 

003 

3 

0E3 

L 

1 

OOE 

U 

ouu 

M 

n» 

005 

s 

OU  5 

ft 

n 

006 

6 

0  It  6 

0 

0 
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7 

0E7 

P 

P 

010 

6 

050 

w 

q 

Oil 

9 

05 

R 

r 

012 

null 

05- 

013 

■ 

0S3 

9 

OIL 

i 

05E 

* 

♦ 

015 

null 

055 

null 

016 

> 

056 

; 

1 

01? 

null 

057 

020 

•  pace 

06C 

null 
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A 

a 

061 

/ 

% 

022 

8 

& 

062 

s 

S 

023 

C 

c 

063 

T 

t 

Q2E 

D 

d 

06  U 

U 

u 

025 

E 

e 

065 

V 

V 

026 

F 

f 

066 

V 

w 
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0 

i 

067 

X 

X 

030 

H 

h 

07G 

Y 

y 

031 

I 

i 

071 

Z 

z 

032 

072 

033 

• 

073 

* 

e 

03E 

) 

J 

07U 

( 

l 

035 
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075 
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< 

¥ 
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? 

n 

077 
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III  inter-core  Controller 
A*  General 

The  inter-core  controller  controls  transfer  of  date  between 
external  core  (often  referred  to  as  *xcQre")  and  910  core.  It 
huff  two  nodes  of  operation! 

(1)  A  block  transfer  node  allows  the  transfer  of  blocks  of 
up  to  2016  words  between  an y  two  locations  in  the  two  cores. 
This  transfer  can  be  between  two  location*  in  the  sane  core, 

(2)  A  short  transfer  node  allows  the  transfer  of  snort, 
fixed-length  buffers  between  fixed  locations  in  910  core  and 
external  core. 

Fixed  core  assignments  for  the  inter-core  controller  arei 

URC,  910  c«re  53 

Fixed  transfer  address,  Xcore  loo 

interrupt  215% 

0.  EOM  Instructions 

Four  SOM  instructions  are  used  for  the  inter-core  controller. 

The  £0K  codes  are? 

20230103  Block  transfer 

20230203  Xcore  to  910  fixed  transfer 

20230303  910  to  Xeore  fixed  transfer 

20230103  .Disconnect 

The  EQM  actions  are: 

Block  Transfer  —  Thia  eom  starts  a  vax iable-length 
transfer.  The  number  of  words  to  be  transferred  and  the 
starting  addresses  in  source  core  and  destination  core 
art  determined  by  the  contents  of  three  consecutive  910 
aesory  cells  starting  with  the  URC*  Source  and 
destination  may  be  in  the  same  core. 

Xcore  to  910  fixed  transfer  —  This  EOM  initiates  a 
transfer  of  a  fixed  number  of  words  beginning  at  a  fixed 
address  in  Xcore  to  a  location  beginning  at  the  URC  in 
910  core,  starting  witn  the  URC  address  in  the  910 
computer  to  a  fixed  starting  address  in  the  external 
core. 
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The  number  of  words  is  determined  by  a  card  ir.  the 
controller  and  may  be  set  to  any  number  between  1  and 
7.  The  number  currently  used  is  } t 

940  te  Xcore  fixed  transfer  --  This  EOM  initiates  a 
transfer  of  a  fixed  number  of  words  (same  number  as 
aoove)  from  9U0  core  to  Xcore,  with  the  same  fixed 
locations  in  each, 

disconnect  --  This  EOM  terminates  any  transfer  in 
progress  and  Diacei  tne  controller  in  the  disconnect 
state. 

C.  Unit  Reference  cell 

The  URC  and  the  next  two  cells  have  the  following  coding  when 
used  to  control  \  bloc*  transfer  operation! 

0  3  5  *  23 


(00011  i  l  1 


ID  I  word  count 

Bitr  Q-3  contain  ar.  idsntification  code.  If  any  other  code 
is  detected,  the  controller  disconnects  and  writes  an  error 
code  in  the  URC. 

Bit  5  is  net  *0  1  If  tr.  interrupt  is  desired  at  the 
completion  of  the  transfer  cycle. 

Bits  6-23  indicate  the  number  of  words  to  be  transferred. 
Bit®  It  and  6-7  are  igr.orea. 

The  cell  URC+1  contains  information  relating  to  tne  destination 
of  the  transfer.  It  has  the  following  format: 

0356  23 


(0001:  s  : 


ID  d  destination  address 

Bits  0-3  contain  an  identification  code  as  above. 

Bit  5  specifies  the  destination  core.  A  1  indicates 
transfer  to  9L0  cere  and  a  0  indicates  transfer  to  xcore. 
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3it.«  6-23  designate  the  first  .•  <udre*«  in  the  destination 
core. 

The  cell  URC*2  contains  information  relating  to  the  source  for 
the  transfer.  It  ha*  th*  following  format: 

0356  23 


:  o  o  o  1 1  s  t  : 


check  u  source  addreas 

Bit*  0»3  contain  an  identification  code  a*  aoove. 

Bit  5  specific*  the  source  core.  A  1  indicates  transfer 
fror/»  the  9u0  core  and  a  0  indicat.,*  transfer  from  xcore. 

Bit*  6-23  designate  the  first  address  in  the  source  core. 

0.  Exit  Routine 

At  the  end  of  any  transfer,  or  when  an  error  is  detected,  the 
exit  routine  1*  perforated.  This  routine  write*  the  URC  and 
then  places  the  unit  in  its  "disconnect"  state.  The  URC  is 
written  with  the  following  format: 

0237  23 


i  :o  o  o  o  oi  : 


error  word  count 

Bit*  0-2  contain  an  error  code.  The  errors  are  reported  as 
follows: 

Bit  0  is  set  to  1  if  any  error  is  detected. 

Bit  1  1*  set  to  1  for  an  er/or  in  any  of  the  URC 
location*  (incorrect  ID  code  det*:ted). 

Bit  2  it  set  to  1  if  the  controller  vaited  more  than  1 
millisecond  to  gain  access  to  the  external  core. 

Bits  3-7  are  set  to  0, 

Bits  6-23  contain  the  content®  of  the  word-count  register 
at  the  end  of  the  transfer.  For  &  successful  transfer 
tale  will  be  0. 
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r* 


* 


An  interrupt  is  issued  at  tne  end  of  the  exit  routine  if  called 
for  by  the.-  URC,  or  if  any  error  has  been  detected.  No 
interrupt  is  issued  for  the  short  transfers. 

IV  Network  interface 

A.  General 

The  network  interface  provides  communication  between  the 
and  an  Interface  Message  Processor  (IMP)  on  the  ARPA  Computer 
Network.  The  interface  operates  from  message  buffers  in  9L0 
core.  A  "linxed-buff er"  scheme  permits  flexible  memory 
allocation. 

The  interface  contains  two  independent  logic  systems,  the  input 
controller  and  the  output  ;ontrolier.  The  former  receives 
information  from  the  Network,  and  the  latter  sends  information 
to  the  Network, 

As  seen  cy  the  programmer,  these  two  units  are  almost 
identical  in  all  aspects  except  the  direction  of  data  flow. 
Differences  between  the  two  are  noted  in  following  sections. 

The  two  channels  are  independent  in  action,  except  that  they 
share  the  same  channel  into  memory.  Thus  they  cannot  make 
simultaneous  core  accesses. 

Fixed  location*  assigned  to  the  Network  interface  arei 


Receive  URC 

60 

Send  URC 

70 

Receive  interrupt 

212 

3end  interrupt 

213. 

B.  communications  with  tne  IMP 

Data  moving  between  the  host  and  tne  IMP  is  in  the  form  of 
serial  bit  strings  with  s-  maximum  length  of  609 1>  bits  and  a 
maximum  rate  of  one  million  bits  per  second. 

Details  of  the  communications  protocol  between  the  ir*~:face 
and  the  IMP  are  covered  in  Ref.  2. 

c.  EOH  instructions 

EOM  Codes  arei 

20P30101*  Host  up 
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2023020A  Initiate  receive 
2023Q30li  Initiate  send 
2023010k  Reset, 

The  "host-up*  EOM  resets  the  "host-up  timer,"  This  is  a 
timer  in  th«  interface  controlling  a  signal  to  the  IMP 
indicating  that  the  boat  computer  is  up.  if  the  timer  it 
not  reset  at  least  once  a  second,  indication  is  given  to  the 
IMP  that  the  host  ia  down. 

The  "initiate  receive*1  eqm  enable#  a  "receive"  operation, 
subsequent  to  tnis  eom,  data  received  from  the  IMP  will  be 
written  in  the  "receive"  buffers.  The  EOM  must  oe  given  for 
each  message  received.  The  controller  may  be  left  in  the 
"receive  enabled*1  state  indefinitely,  waiting  for  a  message 
from  the  IMP, 

The  "initiate  send"  EOM  initiates  a  "send"  operation.  Data 
contained  in  the  "send"  puffers  will  be  immediately 
transmitted  to  the  IMP.  A  "send"  SOM  must  be  given  for  each 
message  to  be  transmitted. 

The  "reset"  EOM  causes  both  the  controllers  vo  immediately 
abort  any  operation  in  progress  ar.d  go  to  the  "reset"  state. 

D.  Linked  Buffers 

Linked  buffers  are  used  for  both  "send"  and  "receive"  messages. 
The  format  of  the  linked  buffer  is  as  follows* 

The  first  word  oi  the  ouffer  contains  the  byte  count  for  the 
buffer. 

If  the  oyte  count  is  zero,  the  controller  goes  directly 
to  the  next  buffer. 

A  block  of  n  bytes  tc  be  transmitted  will  occupy  the  r»/3 
core  addresses  immediately  allowing  the  byte  count, 
since  there  are  three  fi-tit  bytes  ir.  each  2k-bit  9kQ 
word.  When  the  last  oyte  does  not  fall  on  a  9k0  word 
fcouncary*  the  action  depends  on  the  operation* 

In  a  "send"  operation,  bytij  remaining  in  the  last 
word  are  ignored. 

In  a  "receive"  operation,  byte*  remaining  in  the  last 
word  are  fill,.  3  with  0's  by  the  controller. 
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The  last  word  of  the  buffer  contains  the  absolute  address  of 
the  next  buffer 

If  the  last  word  contains  all  O' a  in  tne  address  field, 
no  more  buffers  are  processed  and  the  operation  is 
terminated. 

The  first  buffer  of  a  ‘’send'*  or  "receive”  mecaage  alyays  begins 
2  words  after  tne  "send"  or  "receive"  URC,  respectively  (there 
are  two  URCt  -•  see  below). 

The  maximum  message  length  as  determined  oy  the  imp  is  8096 
bits. 

E.  The  Unit  Reference  Cells 

There  are  two  URC  locations  for  the  interface,  one  for  "send" 
and  one  for  "receive,"  There  are  two  words  at  each  location, 
followed  by  tho  first  message  buffer  (cee  above).  The  URCs 
have  the  following  format: 

First  Word: 

0125  23 


J  t  :  *  :  j 


2  T  N  end  of  data 

bit  0  --  Error:  This  bit  is  set  by  the  controller  when 

an  error  is  detected  (see  below). 

Bit  1  --  List  full!  This  bit  indicates  that  the  linked 
buffers  following  the  URC  certain  valid  data.  Its 
interpretation  depends  on  the  operation. 

On  a  "send"  operation  the  controller  expects  to  find 
this  bit  a  1,  indicating  valid  data  to  be  transmitted. 

If  the  controller  finds  this  bit  0  when  t  "send11  is 
initiated,  the  "need*new»list"  bit  will  be  set  to  1 
and  a  "send"  interrupt  issued- 

When  the  "send"  operation  is  completed  tna 
controller  resets  this  bit  to  Oc 

On  a  "receive"  operation  th$  controller  expects  this 
bit  to  be  a  0,  indicating  that  the  buffers  are  ready 
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to  receive  &  message. 

If  this  pit  is  Found  to  be  a  1  when  a  "receive*' 
operation  la  begun,  the  "need-new-list  Pit"  win  ce 
set  and  a  "receive"  interrupt  issued. 

This  Pit  ia  act  to  1  by  the  controller  at  the 
completion  of  a  "receive"  operation. 

Bit  2  «■«  Need  new  Hat:  Thii  Pit  ia  aet  by  the 
controller  to  indicate  that  the  *liat*full"  pit  waa  not 
correct  at  the  beginning  of  an  operation  . 

Bita  5«23  --  End  of  message:  These  bite  are  aet  by  the 
controller  at  the  end  of  a  “send"  or  "receive"  operation. 

At  the  end  of  the  "fend"  operation  these  bita  point  to 
the  last  word  of  the  i„*t  buffer  transmitted.  This  ia 
the  zero  pointer  that  terminated  the  transmission. 

At  the  end  of  a  "receive"  operation  tneae  Pita  point 
to  the  last  word  filled  with  data  from  the  received 

message. 

Bits  3-Ji  are  not  uaed. 

Second  word:  The  secor.  1  word  (UROl)  contains  error  codes 
and  is  described  below. 

F.  interrupts 

Two  interrupts  are  used  pv  the  controller,  one  for  "s»nd"  and 
one  for  "receive." 

At  the  normal  or  error  termination  of  either  a  "send"  or 
"receive"  operation  the  respective  interrupt  ia  issued. 

Qe  Error# 

Errors  are  detected  by  the  controller  f^r  both  "send"  and 
"receive"  opeiatie’is,  and  error  codes  arc  written  into  the 
word*  following  the  "send"  and  "receive"  URCs  respectively. 

The  "IMP  down"  error  applies  to  both  "send"  and  "receive,"  but 
is  reported  as  a  "send"  error  only. 
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MReceive"  errors  are  reported  in  the  wore  immediately 
following  the  ’•receive'’  URS.  The  errors  and  hit  locations 
in  the  error  word  are* 

Bit  19  -■  Message  ^oo  long*  The  message  has  exceeded  the 
maximum  length  of  6096  bits. 

Bit  20  --  IMP  does  not  responds  During  the  transmission 
of  a  message  the  IMP  pauses  for  more  than  100 
milliseconds  between  bits. 

Bit  21  -•  List  space  exceeded*  Space  in  the  linked 
buffer*  has  been  exhausted  and  there  are  more  bits  in  the 
message  from  the  IMP, 

Bit  23  --  IMP  was  down:  Prior  to  this  message  the  IMP 
was  down*  as  Indicated  by  the  *lMP-downH  line. 

"Send"  errors  are  reported  in  the  word  immediately  following 
the  "send*  URC.  The  errors  and  bit  positions  are: 

Bit  19  -•  Message  too  long:  Tne  message  has  exceeded  the 
maximum  length  of  6096  bits. 

Bit  20  -•  IMP  does  not  respond:  During  tne  transmission 
of  a  message  the  IMP  pauses  for  more  than  100 
milliseconds  between  bits. 

Bit  22  -«  IMP-ready  line  is  down:  This  error  is  reported 
only  when  the  controller  is  active  --  that  is,  after  a 
"sand"  or  "receive”  fOM  has  been  issued  and  before  the 
completion  cf  the  indicated  operation. 

Bit  23  ««  IMP  was  down:  Prior  to  this  message  tne  IMP 
was  down  as  indicated  by  tne  "IMP-down"  line. 

V  Precision  Clock 

A.  General  Information 

The  ARC  clock  system  uses  a  high-stability  Hewlett-Packard 
Model  1058  quartx  oscillator  to  drive  two  accumulators.  The 
accumulators  are: 

(1)  An  absolute-time  accumulator  with  an  output  cf  year, 
month,  day,  hour,  minute,  and  second,  updated  once  each 
second 
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(3)  A  relative-tine  aecumulftor  which  consists  of  &  2u-bit 
binary  counter,  This  counter  is  advanced  once  each 
millisecond. 

The  ahort^erm  jitter  of  both  the  absolute  ..r,n  relative 
accumuiato rs  is  10  to  20  milliseconds,  Th'.s  jitter  ia  caused 
by  the  variation  in  the  amount  of  time  required  to  access  the 
9U0  core  memory. 

The  error  caused  by  the  oscillator  drift  rate  is  leas  than  1 
second  every  250  days. 

The  initial  setting  «f  the  absolute  time  is  accurate  to  within 
1  second. 

The  programmer  has  no  control  ov^r  the  operation  of  this  unit, 
Ti»e  is  written  in  cjre  whenever  the  system  is  operative, 

9,  word  Formats 

Tht  absolute  time  is  written  once  each  etcond  into  two  words  of 
the  9k0  computer. 

The  format  of  the  £!: it  word  lei 


0 

7  6 

15 

23 

1 

: 

s 

1 

month 

day 

year 

Bits  0-7  contain  the  mo  .th 
ranee  of  l  to  12. 

code  in 

straight  binary  with 

Bits  6-15  contain  the  day  code  in 
range  of  1  to  31. 

straight  binary  with  a 

Bits  16-23 
a  range  of 

contain  the  year 
9  to  99  -- 

’  code  in  straight  binary  with 

format  of 

the  second  word 

1st 

0 

7  8 

15 

23 

1 

* 

1 

i 

hour 

minute 

second 
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91t®  0*7  contain  the  hour  code  written  3n  nr.^Lght  binary 
with  a  range  of  0  to  23. 

Bits  15  contain  the  ralnute  code  written  in  straight 
binary  Itn  a  range  oi  0  to  60, 

Bite  16-23  contain  the  second  code  written  in  *+raight 
blntr;*  with  a  range  of  0  to  60, 

She  relative  tine  ia  written  once  each  millioecond  into  a  fixed 
addresa,  Bits  0-23  contain  tne  relative  tine  in  straight 
binary  code  with  a  range  of  00000000  to  77777777  (octal) . 
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I  Introduction 

This  append!*  rives  a  technics!  description  of  nls  and  extends  the 
overview  riven  in  Sec.  IV-e  of  tne  main  oody  of  this  report, 
covering  the  utility  routines,  command  specification,  and  command 
aljorithms  used  oy  NLS. 

In  addition,  the  special-purpose  languages  (SPLs)  for  command 
specification,  content  analysis,  and  string  construction,  whicn 
are  used  In  large  auction:  of  NLS,  are  discussed  in  some  detail. 

This  appendix  assumes  that  the  reader  is  familiar  with  NLS  from 
the  user's  viewpoint  to  the  level  of  the  NLS'c  User's  Guide. 
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II  Utility  Routines 

The  utility  routinei  in  NIS  fall  into  two  categoiies,  dealing  with 
the  overlay  system  and  with  file  handling. 

The  routines  in  the  overlay  system  provide  mechanisms  for 
changing  the  collection  of  pafea  of  code  in  the  address  space 
of  the  program*  the  file-handling  routines  provide  mechanisms 
for  referencing  and  changing  the  actual  data  bate. 

A.  overlay  System  in  Nis 

1.  General 

The  logical  structure  of  the  overlays  in  NLS  is  a  tree 
structure,  with  the  most  widely  used  code  residing  in  the 
overlays  near  the  root. 

An  overlay  is  confined  to  a  single  page,  in  order  to  make 
efficient  use  of  the  paging  mechanisms  of  the  9 iiO » 

2,  Implementation 

The  overlay  structure  is  implemented  through  two  tables  and 
several  procedures  which  use  them  to  manipulate  the 
relabeling. 

?or  a  given  page  of  program,  there  is  an  entry  in  each 
table.  The  index  of  the  entries  for  the  page  is  the  same  in 
both  tables  and  is  called  the  "overlay  number"  of  the  page. 

One  table  gives  the  relabeling  byte  for  the  page,  wnile  the 
other  gives  the  overlay  number  of  the  parent  overlay  and  the 
position  in  the  address  space  that  the  page  should  occupy. 

The  entries  in  the  second  table  hive  a  POP  code  in  addition 
to  the  other  information.  To  relabel  in  an  overlay  (and  the 
overlays  above  it  in  the  tree),  the  instruction 
corresponding  to  that  overlay  in  the  second  table  if 
executed. 

If  a  call  i*  to  oe  made  to  a  procedure  in  another  overlay 
that  occupies  the  sane  logical  position  in  the  address  space 
as  the  calling  routine,  the  call  is  split  into  two 
instructions. 

These  correspond  to  the  execution  of  two  POP*,  the  first 
of  which  "select!  the  overlay*  and  the  second  of  which 
gives  the  address  to  branch  to  in  that-  overlay. 

Two  cell*  are  used  in  the  program  to  Keep  a  copy  of  the 
relabeling. 
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When  an  overlay  if  selected,  the  overlay  tables  are 
used  to  update  these  words  witncut  chancing  tne  actual 
relabeling , 

This  change  is  made  when  the  second  POP  is  executed 
and  after  the  destination  address  has  oeen  read. 

On  a  call  such  as  this,  the  overlay  number  of  tne  calling 
routine,  as  well  as  tne  calling  address,  is  saved  on  a 
stack. 

This  allows  the  overlays  to  be  restored  to  their  status 
before  tne  call  vnen  the  called  routine  returns. 

The  routines  that  change  the  relabeling  are  in  the  overlay 
at  the  root  of  the  tree,  and  are  tnus  always  available. 

in  general  the  root  overlay  contains  utility  routines  for 
basic  functions,  such  as  changing  relabeling  and  accessing 
elements  of  the  file. 

S,  NLS  Random-File  Structure  and  Handling 
1.  General  considerations 

The  present  format  ana  structure  of  HL3  files  was  determined 
oy  certain  design  considerations. 

It  xs  desirable  to  have  virtually  no  limit  on  the  size  of 
a  file.  This  means  that  it  is  not  practical  to  nave  an 
entire  file  in  core  when  viewing  it  or  working  on  it. 

A  goal  in  the  design  was  to  maxe  the  tine  required  for 
most  operations  on  a  file  independent  of  the  length  of 
the  file,  That  is,  small  operations  on  a  lan;e  file 
should  take  roughly  the  same  time  as  on  a  small  file,  in 
this  way  the  user  and  tne  system  are  not  penalized  for 
large  files. 

The  system  nad  to  include  graphic  statements,  and  perhaps 
other  form*  of  data,  as  well  as  text. 

As  a  result  ox  these  considerations,  a  random«fiie  scheme 
was  chosen.  Each  file  is  divided  into  logical  blocks  that 
may  be  accessed  in  a  random  order.  There  are  several 
different  types  of  blocks,  and  each  type  nas  its  own 
structure. 
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2,  File  St.-ucture 

An  M5  file  is  made  up  of  a  header  and  ud  to  a  fixed  number 
(currently  66)  of  102k-vord  file  block*. 

a.  The  Header  Block 

In  etch  file,  there  is  a  header  block  that  contain* 
information  about  that  particular  file. 

The  header  block  rema-n*  in  memory  while  the  file  1*  in 
use. 

The  header  induce*  the  iollowing  information: 

(1)  General  information  regarding  the  file,  such  as 
the  following: 

(a)  The  date  of  creation  of  the  file 

(b)  The  file  owner ;*  user  number  (identifier  the 
ueer  who  created  the  file) 

(c 5  The  number  of  word*  in  the  file  header  block 

(d)  The  initial*  of  the  user  who  last  wrote  thj 
file  out 

(e)  The  date  and  tine  at  the  last  writing 

(f)  The  name-delimiter  characters 

{%)  Tne  average  length  of  statement *  in  characters 

(h)  The  total  numter  of  statement*  generated  in 
the  life  of  the  file. 

(2)  Status  table*  for  the  file  block*. 

The  first  and  largest  statu*  table  is  the  random  file 
block  status  ( RFBS )  table. 


Each  entry  in  the  ariS  table  correspond*  to  * 
random  file  block,  and  indicate*  the  st#tu*  of  that 
Mock,  The  file  header  is  file  Mock  zero.  The 
number  in  the  RFBS  entry  ha*  one  of  the  follewirg 
meaning*: 
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ZERO:  The  block  is  not  allocated,  and  does  not 
exist. 

POSITIVEi  The  olock  is  allocated,  and  is  in 
memory  rather  tnan  on  the  secondary  storage 
device.  The  positive  number  is  the  actual 
starting  address  for  the  block, 

NEGATIVE:  The  block  is  not  in  core.  If  the 
entry  equals  -1,  then  the  clock  is  allocated, 
but  has  not  been  initialized.  In  the  case  of 
text  blocks,  -2  indicates  that  the  block 
contains  no  garbage  statement  data  blocks,  and 
need  not  be  zaroaf e-collectea,  otherwise  the 
number  is  the  negative  of  the  used-wora  ccunt. 

A  given  file  block  has  only  one  type  of  information, 
such  as  structure  or  text.  There  is  a  separate  status 
table  for  each  type  of  file  clock.  These  are  called 
secondary  status  tables. 

An  entry  in  such  a  table  has  one  of  the  following 
meanings! 

ZERO :  The  block  is  not  allocated, 

NON-ZERO i  The  value  is  the  block  number,  that  is, 
the  entry  into  tne  R*BS  for  tnat  block. 

There  are  aecorcary  status  tables  for  structure,  text, 
graphics,  and  keyword  types  of  file  blocks.  The 
internal  structure  of  these  different  types  of  blocks 
is  discussed  in  the  following  sections. 

The  use  of  separate  status  tables  avoiaM  references  to 
absolute  locations  in  the  file  and  reduces  the  number 
of  bits  required  to  specify  the  location  cf  a 
particular  piece  of  information, 

pointers  to  various  elements  (structural,  textual, 
etc.)  consist  of  two  fields:  a  secondary 
itatus-table  index  and  an  address  giving  the  start 
t:  the  element  relative  to  the  start  of  the  block. 
The  status  table  entry  contains  the  number  of  the 
block,  from  which  its  absolute  address  can  be 
computed. 

rower  bits  are  required,  since  the  range  of 
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secondary  status-table  indexes  is  smaller  than  the 
ranie  of  possible  file-block  numbers,  The  greatest 
gain  from  this  is  m  the  identifier  for  a  ring 
element,  since  a  file  can  have  only  eight  structure 
blocks  in  the  current  configuration  of  NIS . 

In  spite  of  this,  the  use  of  the  separate  status 
tables  is  of  questionable  value. 

Value  of  Avoiding  Absolute  Addressees  By  avoiding 
absolute  addresses  in  the  file  it  is  possible  to  move 
a  block  to  a  new  location  in  the  file  simply  by 
changing  a  status-table  entry,  such  a  move  can  be 
valuable  if  the  file  has  become  sparse  and  needs  to  ce 
compacted. 

If  absolute  addresses  were  used,  then  all 
references  to  the  blocK  would  have  to  be  changed, 
but  it  can  be  argued  that  sucn  a  process  need  only 
be  done  on  rare  occasions  and  hence  its  efficiency 
is  not  crucial. 

Moreover,  sufficient  backpointers  exist  so  that 
the  process  of  modifying  references  would  not  pe 
difficult  (although  it  night  be  lengthy). 

Value  of  Fewer  gits  in  pointers*  The  economy  of  bits 
in  pointers  is  a  stronger  argument  for  the  use  of 
secondary  status  tables.  However,  the  total  savings 
per  ring  element  (with  the  current  siie  limits  on 
files)  is  only  six  bits. 

Disadvantages  of  Secondary  status  Tables*  space  in 
the  data  page  is  used  by  the  tables  (which  are  always 
in  core)  for  information  that  would  not  be  necessary 
if  absolute  addresses  were  used. 

Their  use  places  arbitrary  limits  on  the  number  of 
file  blocks  of  t  particular  type. 

For  example,  it  is  possible  to  exhaust  the 
structure  blocks  when  the  file  actually  contain* 
roor.  for  more  information,  if  absolute 
addresses  were  used,  then  blocks  of  a  particular 
type  could  be  allocated  as  needed,  with  a  limit 
only  on  the  total  number  of  block*  rather  than  a 
limit  on  eacn  type  of  block. 
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If  further  consideration  confirms  that  the  secondary 
status  tables  should  be  eliminated,  it  will  not  t>e  a 
difficult  task  because  of  the  methods  used  for 
accessing  information  in  tne  files. 

These  methods  are  discussed  in  a  later  section; 
first  the  remainder  of  the  file  structure  must  be 
described. 


b.  File-Block  Format 

Each  random  file  Dios*  has  an  eifht-vord  neader.  Tnis 
header  contains  the  following: 

(1)  The  checksum  of  une  clock 

This  is  computed  before  the  block  is  written,  and 
verified  when  the  block  is  read.  In  addition,  if 
room  in  core  is  needed  for  a  block,  then  any  Hock 
in  core  that  has  not  been  changed  may  be 
overwritten  without  copying  it  to  tne  file.  The 
checksum  provides  an  easy  means  of  testing  whether 
the  block  has  been  changed. 

(2)  The  used-word  count  (always  greater  than  the 
neader  size) 

(3)  The  block  type,  to  indicate  whether  the  block  is 
text  or  structure 

U)  in  structure  blocks,  tne  free-list  pointer;  in 
text  blocks,  the  garbage-collection  flag,  indicating 
whether  there  are  garbage  SDas  (statement  data  blocks) 
in  the  block. 


(5)  The  secondary  status-table  index  number. 


c.  Structure  Blocks 


The  internal  structure  of  NLS  files  is  n  ring  structure 
representing  a  tree  structure.  Each  nods-  in  the  ring 
corresponds  to  a  statement,  and  contains  pointers  to  the 
"first  son*  (called  the  sub)  and  the  "first  brother" 
(called  the  successor).  The  last  node  in  a  list  contains 
a  flag  marking  it  as  tne  tall  and  points  to  the  father  as 
its  successor. 


The  nodes  in  the  ring  are  Kept  in  four-word  rang 
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elements. 

Each  structure  clock  contain*  251  ring  elements,  There 
can  be  up  to  eight  structure  block*  in  a  file,  but  not 
all  need  be  allocated. 

Each  ring  element  in  an  allocated  block  either  1* 
associated  with  a  statement  in  the  struct-;.  *  of  the  file 
or  is  on  the  free  list  for  the  block, 

A  free  list  consists  of  a  chain  of  pointers*  starting 
in  the  block  header  and  ending  with  a  aero  pointer. 
(As  used  here  a  pointer  is  an  address  relative  to  the 
start  of  the  block.)  The  pointers  are  in  tne  first 
word  of  the  four-word  element,  and  the  other  three 
words  are  zero, 

A  free  list  is  entirely  contained  vithin  a  single 
block  in  order  to  Minimize  file  references, 

A  ring  element  associated  with  a  statement  contains  the 
following  information i 

(1)  Flag*  indicating  whether  the  statement 

(a)  has  a  name  or  not 

(b)  has  been  tested  against  the  current 
content-analyzer  pattern 

(c)  passed  tne  pattern,  if  it  has  been  tested 

(d)  is  the  head  of  it*  plex 

(e)  is  the  tail  of  its  plex 

(2)  A  pointer  to  the  text  for  the  statement 

(3)  A  pointer  tc  the  picture  associated  with  t.ie 
statement  if  there  is  one 

(k)  A  pointer  to  the  aub  for  the  statement  (or  a 
pointer  to  the  statement  itaelf  if  there  is  no 
substructure) 

(5)  A  pointer  to  the  successor  for  the  stitement 
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(6)  The  hash  of  the  name  of  the  statement  if  it  has  a 
name. 

A  ring  element  is  pointed  to  by  a  permanent  statement 
identifier  (PSID). 

This  is  an  11-bit  integer  between  0  and  20a7. 

The  three  high-ord*r  bits  live  the  structure-block 
number  (entry  into  the  RSVST  table),  and  the  eight 
lew-order  bits  determine  the  location  within  tne 
block. 

The  PSID  of  a  statement  remains  unchanged  as  long  as 
that  statement  is  in  the  file.  That  is,  the  PSID  is 
not  changed  by  textual  or  structural  editing  of  the 
file.  When  the  statement  is  deleted,  that  same  PSID 
may  later  be  used  to  identify  a  different  statement. 

Every  file  has  at  least  one  ring  element  in  Its 
structure,  namely  the  element  for  the  origin  statement 
(root  of  the  ring,  first  statement  in  the  file),  which 
always  has  PSID  zero, 

d.  Text  Blocks 

In  addition  to  the  header,  a  text-type  file  block  is  made 
up  of  an  arbitrary  number  of  statement  data  blocks  (SDB*) 
and  an  area  of  free  storage. 

The  free  storage  area  at  the  end  of  the  file  block  is 
simply  a  number  of  woros  available  for  use  in  creating 
new  SDBj . 

An  SDB  is  a  variable-sized  block  of  words  with  a  six-word 
header. 

The  header  contains  the  following  information: 

(1)  The  number  of  words  in  the  SDB, 

(2)  k  flic  indicating  whether  the  SDB  is  unused 
(i.e.  garbage  to  be-  collected  by  the  garbage 
collector) 

(3)  The  PSID  of  the  statement 

U)  The  date  and  the  tine  when  the  SDB  was  created 
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And  the  initiAls  of  the  u*er  who  created  it 

(5)  The  numbe*  of  characters  in  the  statement 

(6)  The  position  of  the  first  character  in  the 
statement  th*t  is  not  part  of  the  name,  (Set  to  1 
if  the  statement  does  not  have  a  name,) 

The  words  followini  the  header  contain  the  text  of  the 
statement,  three  characters  per  word*  The  text  includes 
an  end  character  (code  3770.'  on  each  end  of  the 
statement.  The  last  verd  is  filled  to  a  word  boundary 
with  end  characters. 

The  characters  in  a  statement  are  explicitly  numbered, 
the  first  end  character  being  number  zero, 

A  two-word  entity  consisting  of  a  PSXD  and  a  character 
count  is  called  a  T-pointer,  and  indicates  a  particular 
character  within  the  file. 

A  T»string  is  a  string  of  text  within  a  single  statement. 

The  text-editing  routines  make  use  of  T-pointers  and 
T-strings. 

e.  Graphics  Blocks  and  Keyword  dock 

The  format  of  the  information  stored  in  these  blocks  will 
be  described  in  the  sections  dealing  with  the  vector 
paoksge  and  the  keyword  system. 

3.  Tile  Handling 

a.  Core  Tables  and  File  input/output 

The  random  files  are  read  into  core  by  blocks.  Two  pages 
in  NLS  are  logically  divtdod  into  four  I02k-word  sections 
to  contain  the  file  blccks.  Thus,  up  to  four  file  blocks 
may  be  In  core  at  a  time,  when  a  file  block  is 
requested,  if  all  feur  are  in  use,  one  block  will  be 
written  out.  Core  blocks  may  ee  "frozen"  in,  nowever,  so 
that  they  will  not  be  removed, 

A  single  procedure  called  LODRFd  controls  all  file 
input/output  (other  than  file  copying),  When  any  routine 
wants  a  block  loaded,  it  calls  this  procedure  with  the 
number  of  the  desired  clock.  The  block  ie  then  loaded 
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and  its  location  in  mercery  returned. 

The  procedure  makes  use  cf  several  tables. 

One  table  indicater  which  file  block  is  in  ram 
core  block  (it  is  called  RFIFCP  for  "random  file 
index  for  core  blocks").  A  zero  in  this  table 
Reins  that  nc  file  block  is  there,  While  a  positive 
number  13  the  random  file  block  nunoer  (index  to 
RFbS )  , 

A  becond  table  indicates  whicn  of  the  core  blocks 
have  been  irozen.  “Frozen"  indicates  to  the  file 
block  loading  procedure  that  the  cere  olock  must 
not  be  changed.  This  is  the  case  if  some 
operation,,  such  as  editing,  is  ceir<  performed  or. 
data  within  the  block, 

A  value  in  tne  table  cf  -1  '.cans  that  the  block 
is  not  frozen;  this  value  is  incremented  cy  1 
for  each  reason  wr.y  tne  uIock  is  frozen* 

The  algorithm  of  LODKFb  is  approximately  a*  follows: 

Firot,  a  core  block  is  cnosen,  A  quick  scan  of  the 
first  table  mentioned  aDove  is  made  to  find  an 
unused  block,  if  all  are  in  use,  teen  a  counter  is 
used  to  find  the  next  core  block  that  Is  not 
frozen,  (If  all  are  frozen  tne  system  abort*.) 

The  counter  provides  a  simple  algorithm  for 
determining  which  block  should  be  removed  from 
core. 

If  the  chosen  core  block  contains  a  file  clock, 
then  one  of  the  following  things  happens: 

(1)  If  the  file  block  is  empty,  it  is  released 
to  the  system  and  tne  corresponding  status  block 
is  set  to  indicate  tint  that  block  is 
unallocated, 

(2,  Otherwise,  the  block  is  written  out  on  the 
file  if  the  checksum  has  changed,  and  the  random 
file  status  olock  is  set  to  indicate  that  the 
block  is  on  the  file  and  not  in  core. 


At  this  point  the  desireu  file  Mock  is  loaded  into 
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the  core  block. 

If  the  random  file  block  nas  not  been  .nitialized, 
the  initialization  if  done  now.  otherwise  the 
checksum  ard  file  type  are  checked.  An  error  ±a 
reported  if  either  of  the*e  checks  fails. 

Finally,  the  ranuozn  file  block  status  is  set  to 
show  that  the  block  is.  now  in  core,  and  the  index 
for  core  blocks  (RFIFCB)  is  set  to  indicate  which 
random  file  block  is  in  that  cere  block. 

b.  File  copying 

The  algorithm  for  copying  an  NL3  file  is  as  follows: 

First,  the  procedure  must  obtain  a  core  block  to  do 
the  copying.  RFIFCB  is  scanned  to  find  a  block  tnat 
is  not  used.  If  there  is  no  unused  block,  then  the 
first  block  that  is  not  frozen  is  taken,  and  the  file 
block  number  in  it  is  saved.  That  block  is 
chrckaumoed  and  written  out  on  the  output  file  (in  the 
proper  file  block). 

Having  obtained  a  block,  all  of  the  allocated  file 
blocks  (except  for  the  one  already  written  in  the 
event  that  no  core  block*  were  free)  are  copied  from 
one  file  to  the  other.  This  includes  the  file  header* 

Finally,  if  no  blocks  were  free,  the  block  which  v*s 
removed  to  make  room  for  the  copy  is  restored  from  the 
output  file. 

c.  Referencing  information  in  ths  File 

A«  much  as  possible,  information  in  the  file  ia 
referenced  indirectly  through  utility  functions.  This 
ensures  that  the  file  structure  can  be  modified  with 
minimal  changes  in  the  system  as  a  whole. 

For  each  field  in  the  ring  element,  there  are  procedures 
wnich,  given  a  P3ID  as  argument,  either  read  the  contents 
of  the  field  or  store  a  new  value  into  it. 

only  these  procedures  need  know  the  actual  format  of  a 
ring  element.  Thus  only  these  procedures  need  be 
changed  if  that  format  is  modified. 
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mere  are  also  procedures  for  readme  and  writing 
characters  in  an  SOB.  This  serves  both  to  ensure 
flexibility  in  the  format  of  the  9DB  and  to  avoid 
multiple  procedures  for  performing  a  very  common 
functions 

Because  of  the  lack  of  instructions  for  character 
manipulation  on  the  9k0,  a  rather  elaborate  metnod  u 
used  to  read  characters  from  a  statement. 

Before  any  characters  are  read,  the  orocefiure  FECHCl 
is  called  to  initialize  a  work  area.  It  is  called 
with  the  address  of  the  work  area  and  tne  direction  in 
which  characters  are  to  be  read  from  the  statement. 

When  calling  FECHCl,  the  first  two  cells  of  the 
work  area  must  contain  a  T-pointer  for  the  first 
character  to  be  read,  A  character  count  oi  one 
indicates  the  first  character  of  the  statement. 
FECHCl  will  initialize  the  rest  of  the  work  area, 
which  contains  the  following: 

WORD  0:  PSID 

WORD  1:  character  count 

WORD  2s  return  adcress  fer  routines  reading 
characters 

word  3s  instruction  to  branch  indirectly  through 
the  fourth,  fifth,  or  sixth  cells  ,f  tne  vor* 
area 

WORDS  k,  5,  and  6i  address  of  code  to  pass  the 
first,  second,  or  third  character  respectively 
of  the  current  word  of  text 

WORD  ?i  address  of  the  current  word  of  text 

WORDS  6,  9»  and  iQi  the  first,  second,  and  third 
characters  in  the  current  word  of  text 

WORD  11:  unused 

word  12:  the  address  of  the  start  of  the  first 
word  of  text  in  the  SDB. 

After  the  work  area  has  oc^n  initialized  by  calling 
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FEGHC1,  any  number  of  characters  nay  ce  read  from 
the  statement  by  simply  executing  a  call  to  tne 
second  cell  of  the  work  area.  After  returning  the 
last  character  of  the  statement  (or  first  if  the 
direction  of  readout  is  backwards),  end  characters 
(code  377B)  will  be  returned  from  all  subsequent 
calls. 

The  call  to  the  work  area  places  the  return 
location  in  the  second  cell  and  causes  the 
instruction  in  the  third  cell  to  be  executed,  Tnis 
results  in  a  branch  to  a  routine  wmch  returns  the 
next  character. 

when  all  the  characters  from  a  particular  word 
have  been  read,  the  next  word  of  text  is 
unpacked  into  the  appropriate  cells  in  the  work 
area. 

Whenever  a  character  is  read,  the  branen 
instruction  in  the  third  cell  of  the  work  area 
is  modified  so  that  the  next  call  will  result  in 
a  branch  to  the  appropriate  routine  to  read  the 
next  character. 

To  chance  position  within  the  statement,  chance 
direction,  or  read  from  a  different  atatment,  the 
work  area  must  be  reinitialized  by  calling  FECHCl 
again,  as  described  above. 

Finally,  statements  may  be  read  in  sequence  according  tc 
Yiew  parameters  by  means  of  a  group  of  procedures 
collectively  called  the  "sequence  generator, H  This  is 
described  in  detail  in  sec.  IV*0»2  of  this  appendix. 

It  was  mentioned  above  that  it  would  be  possible  to 
eliminate  the  secondary  statue  tables  without  an  undue 
amount  of  effort. 

It  should  be  evident  now  that  this  is  in  fact  the  case 
as  a  result  of  the  use  of  functions  to  reference 
information  In  the  file. 

It  would  be  possible  to  modify  the  field  sizes  in  the 
ring  element  sy  simply  rewriting  the  routines  that 
access  the  affected  fields. 

In  addition,  a  simple  process  could  be  written  to  take 


215 


Appendix  Dl  TECHNICAL  DESCRIPTION  OF  NIS 
See.  II:  Utility  Routines 


iiles  in  the  current  NLS  t ornat  and  convert  then  to  % 
format  uiins  Absolute  addresses  for  pointers  retner 
than  status  tables. 


216 


Ill  command  Specification 


A.  command  Specification  in  NLS 

1.  General 

The  command  specif ication  section  of  NLS  is  implemented  in 
an  3PL  deaiined  to  facilitate  its  description  and 
implementation* 

The  details  of  this  language  and  its  use  in  NLS  are 
explained  in  the  following  sections. 

2,  Registers  in  the  command  specification  Language 

Two  types  of  registers  are  used  by  the  command  specification 
machinery!  string  registers  and  character  registers. 

Some  of  the  registers  are  used  internally  in  the 
implementation  of  the  language,  some  are  used  as 
special-purpose  registers  for  operations  on  certain  types 
of  operands,  and  some  are  general-purpose:  operand  and 
storage  registers. 

constructs  in  the  input-f eedbacx  SPL  allow  manipulation 
of  the  string  ^nd  character  registers. 

The  principal  defined  operations  for  string  registers 
are  LOAD  and  DISPLAY. 

The  contents  of  a  string  register  are  normally 
designated  in  the  SPL  as  the  name  of  the  register 
immediately  followed  by  an  asterisk  («). 

A  register  may  be  assigned  a  value  cv  a  statement 
of  the  form 

register-name  *+m  M*M  expression. 

Examples  of  expressions  are! 

(1)  The  name  of  any  of  the  string  or  character 
registers 

(2)  The  designation  cf  a  character,  such  as  sp 
for  space 

(3)  The  character  0,  meaning  to  set  the  string 
to  null 

U)  A  string  of  text  delimited  by  ^-pointers, 
for  example,  LIT**0  clears  the  literal  input 
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register,  while  LIT*«(B1  B2)  loads  it  with  the  a 
tezt  string. 

The  contents  of  a  register  nay  be  displayed  in  the 
name  area  by  tne  con  no  of  the  form 

"DN("  register -name  ")». 

Thus  D N  ( S T h * )  causes  the  contents  of  the  statement 
name  register  to  be  displayed. 

The  input  character  register  is  normally  available  to 
the  3FL  programmer  as  a  read-only  register,  which 
always  contains  the  last  character  read  from  the  input 
string. 

The  contents  of  the  register  may  oe  put  into  a 
string  as  described  above,  or  displayed  in  the  text 
area  by  writing  DT(C*). 

in  addition,  the  input  character  is  implicitly 
referenced  in  the  case  statement  (described  in  Sec. 
III-A-b  of  this  appendix) e 

,1*.  Entity  Character  and  Entity  string]  Command  Oroups 

The  commands  in  NLS  are  classified  in  groups,  and  with  each 
group  ia  associated  a  particular  entity  (such  as  character, 
word,  statement,  nr  branch). 

with  this  entity  is  associated  a  character  called  the 
"entity  character"  and  a  string  called  the  "entity  string." 

The  entity  character  is  programmatically  assigned  values  in 
the  SPL  by  the  construct 

character  string. 

This  causes  the  entity  character  to  be  set  to  tne  value 
of  the  character,  and  assigns  the  value  of  the  string  to 
the  entity  string. 

Thus  "E**B, BRANCH"  sets  the  entity  character  to  "B"  and 
the  entity  string  to  "BRANCH  t  M 

The  entity  string  and  entity  character  are  used  to  provide  a 
cefault  option  in  command  specification. 
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When  the  command  operation  (such  as  DELETE)  ha  a  been 
specified,  the  entity  string  for  the  group  of  the 
operation  ia  offered  as  the  type  of  entity  for  the 
command.  The  user  may  accept  this  oy  typing  a  '-command 
accept"  character  (CA)  or  specify  some  other  entity  by 
typing  the  appropriate  character* 

The  actual  SPL  constructs  used  to  express  this  use  of  the 
entity  string  and  entity  character  are  Dresented  in  a  later 
example. 

k.  Command  State 

Except  when  a  command  is  oeing  epecifiea  or  executed,  the 
user  is  in  some  command  state. 

If  the  user  begins  parameter  specification  without  first 
specifying  a  new  command,  the  command  executed  will  be  tnat 
designated  by  the  current  command  state. 

The  command  state  ia  defined  internally  by  a  special 
register  called  the  "state  register," 

The  state  register  always  contains  the  location  of  the 
most  recently  defined  command  state. 

This  location  ia  in  the  same  format  as  a  return 
location  placed  on  tne  atac*  in  a  subroutine  call. 

The  state  register  additionally  contains  the  command 
group  of  the  command  state, 

The  SPL  syntax  for  defining  a  command  state  is 

"3»«"  label  command-group, 

which  results  in  a  call  to  the  state  defining  routine  to 
be  produced  by  the  compiler.  The  label  is  defined  as 
being  equal  to  the  address  of  this  instruction. 

From  the  command  state,  control  passes  directly  to  a 
parameter  specification  point  in  the  program,  which  actc  a s 
an  idle  or  "wait  for  next  input"  point. 

Control  returns  to  the  highest  level  of  the  command 
parsing  code  if  the  character  read  is  not  a  legitimate 
parameter  specification  character. 
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This  io  one  of  the  most  significant  features  in  marine 
the  command  language  efficient  and  easy  to  use. 

The  contents  of  the  state  register  may  be  used  as  an  operand 
in  aesignationni  expressions. 

Thus,  one  may  programmatically  return  to  the  previous 
command  state  by  the  SPL  statement  "goto  ($]" . 

There  are  several  occasions  where  this  construct  is  used. 

At  any  time  during  the  command  specification,  a  user 
ru.y  return  to  his  previous  command  state  by  typing  a 
"command  delete54  character  (CD). 

From  tne  above  description  of  command  state,  it  may 
be  seen  that  the  action  of  a  command  delete  is  to 
reset  any  parameters  entered  during  the  course  of 
the  aoorted  command  and  branch  to  the  location 
contained  in  the  state  register. 

If  a  specification  error  occurs  during  the  execution 
of  a  command,  the  command  is  aborted  and  NLS  is 
automatically  returned  to  the  previous  command  state. 

5.  Command  parsing 

The  NLS  input  commands  are  parsed  through  the  use  of  nested 
case  statements. 

The  depth  in  the  nest  of  case  statements  corresponds  to 
ne  position  of  the  next  character  to  be  retd  in  the 
command  input  string. 

Thus  if  a  command  were  specified  by  „hree  characters, 
the  first  character  would  be  read  by  a  first-level 
case  statement,  the  second  by  a  second-level  case 
statement,  and  the  third  by  a  third-level  case 
statement. 

Two  features  of  the  case  statement  construct  in  the 
input-feedback  SPL  make  it  especially  suited  for  oarsing 
the  command  input  strings. 

The  selection  criterion  for  the  execution  of  an 
element  of  the  case  statement  is  equality  of  two 
specified  characters,  one  of  which  appears  at  the 
front  of  t;.e  element,  the  other  of  which  is  implicit, 
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The  implicit  character  iff  normally  the  last 
character  read  from  the  input  string,  in  addition, 
it  iff  poffsi&le  to  repeat  a  case  (using  a  "REPEAT" 
construct)  with  some  character  other  than  the  input 
character. 

in  particular,  the  entity  character  may  be  used. 
This  permit*  the  implementation  of  the  command 
default  option  mentioned  above. 

At  the  head  of  the  case  statement,  the  entity 
string  is  used  to  offer  a  default  value  of  the 
command  type.  If  the  user  types  a  command 
accept,  there  is  an  element  in  tne  case 
statement  which  is  executed  and  results  in 
repeating  the  case  statement  using  the  entity 
character  in  place  of  the  input  character. 

The  net  effect  is  the  same  *e  if  tne  user  had 
tyi.ed  the  entity  character  rather  than  a  command 
accept. 

If  none  of  the  tests  succeed,  then  ar.  "L"  -'iCASE'* 
statement  is  executed. 

Whenever  a  case  statement  is  executed,  an  entry  is 
made  on  a  stack  indicating  the  location  of  that  case 
statement. 

A  construct  in  the  repeat  statement  allows  the 
execution  of  a  previous  case  statement  \<ith  a 
particular  character 

The  word  REPEAT  is  followed  by  an  integer  indicating 
which  of  the  stacked  cases  is  to  be  repeated. 

Thus  REPEAT  2  causes  the  second  previous  case 
statement  to  be  repeated. 

The  integer  is  in  turn  followed  by  a  character- 
specification  in  parentheses. 

This  may  be  any  of  the  following i 

(1)  An  actual  character  to  be  usea,  such  as  SP 

(2)  The  entity  character  (£♦) 
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(3)  ins  next  input  character,  indicated  by  a 
period, 

A  brief  example  of  code  for  parsing  an  NLS-like  command 
language  is  presented  here. 

It  incorporates  most  of  the  SPL  constructs  mentioned  in 
this  section,  as  well  as  some  not  mentioned. 

The  command  language  described  here  allows  two  grouDs  of 
commands,  used  for  text  editing  ano  structure  editing 
respectively. 

Four  commands  are  specified) 

Text  editing t  (initial  entity  ■  character) 

Insert  Character 
insert  Word 

Structure  editing)  (initial  entity  ■  statement) 
Append  statement 
Append  Branch 
(start)  «  case 

(i)  /’textedit;  dsp{  <  insert  t  es*  )  .  case 

(c)  s*«ie,textedit  d*p(  ♦  <  insert  character) 
e#»c, character  ♦parmepec, prmspc  -eomex,exectr 

(v)  B*«iw , textediv  d*p(  *  <  insert  word)  e*«w,word 
♦parmspec,prmspc  -comex,exectr 

(ca)  repeat  0(««) 

(cd)  goto  [§] 

endcase  goto  start 

(a)  /’stredlt;  dsp(  <  append  t  e§*  )  ,  case 

(s)  i**ic* streUt  dsp(  *  <  append  statement) 
e»»«, statement  ^parmspec, prwspc  -comex,exectr 
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(v)  **»jiw,  atredit  dspt  «•  <  append  word)  e**w,vord 
♦  parintipe?,prnape  -comes, exectr 

(ca)  repeat  0(e#) 

(cd>  goto  {*] 

endcase  goto  start 

endcase  repeat  0(.) 

6,  Parameter  Specification 

Parameter  specification  is  tnat  portion  of  NLS  wnicn  is 
involved  with  the  selection  of  operand**  for  commands. 

operands  may  be  specified  oy  selecting  locations  and 
entities  in  a  file,  by  entry  of  strings  from  the  Keyboard, 
or  by  the  naming  of  pointers  with  the  keyset  and  mouse. 

Specifications  of  entities  in  the  file  are  represented  by 
one  or  more  entries  on  a  stack*  called  the  specification 
•tack.  (This  is  independent  of  the  subroutine  argument  and 
return  stack.) 

There  is  one  entry  on  the  specification  stack  for  each 
selection  made  in  parameter  specification. 

A  normal  entry  on  the  specif ication  stac*  (spec  stacK 
for  short)  is  called  T-pointer  (which  consists  of  a 
?3ID  and  a  character  ccunt). 

An  3PL  construct  facilitates  the  placing  of  arguments 
onto  the  spec  stack.  The  syntax  is 

“SPEC  ( M  argument  • )% 

where  an  argument  can  be  any  of  the  following! 

BUOi  Process  the  most  recent  command  accept  as  a 
bug  selection  and  place  the  corresponding  T-pointer 
on  the  spec  stack 

POS:  Load  the  last  bug  selectior  ^nto  the  spec 
•tack. 

String  register!  The  action  of  this  command  depends 
on  the  register  specified,  and  the  contents  cf  the 
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register , 

If  the  register  If  the  number  register,  then  the 
number  string  in  the  register  is  converted  to  *n 
integer  and  pushed  onto  the  spec  stack  aa  the 
second  word 

If  the  specified  register  is  the  statement 
r.uaber  register,  it  converts  the  string  in  the 
register  (assumed  to  be  a  statement  number)  into 
a  PSID,  and  pushes  it  onto  the  spec  stack 

in  the  case  of  any  other  register,  if  the  first 
character  in  the  string  is  &  digit,  then  the 
content  of  the  register  is  assumed  to  oe  a 
statement  number,  otherwise,  a  statement  name. 

In  either  case  the  corresponding  PSID  is  pushed 
onto  the  stack. 

Number:  The  integer  indicated  is  pushed  onto  the 
spec  stack 

Identifier!  The  value  of  the  identifier  is  pushed 
onto  the  spec  stack 

(no  argument) !  This  causes  the  spec  stack  to  be 
cleared  of  all  entries, 

A  textual  entity  may  ic  specified  (effectively)  only  through 
pug  selection^)  or  with  a  pointer. 

A  atructural  entity  may  be  specified  by  bug  seiection(s) ,  a 
pointer,  or  keyboard  entry  of  statement  name (a)  or 
number (s) . 

in  the  case  where  the  bug  selection  or  pointer  serves  as 
a  text  selection  whicn  indicates  a  string  identifying  the 
statement  to  be  specified  (s.g*,  names,  links),  the 
•elected  string  is  moved  into  a  string  register  and 
treat  as  though  it  were  entered  from  the  keyboard. 

The  algorithms  for  converting  bug  selections  into  i-pointers 
are  discussed  in  3ec,  IV-3-fe-c  of  this  appendix, 

A  pointer  is  simply  a  T-pointer  which  has  been  given  a  name 
and  stored  in  a  table. 

It  is  specified  by  depressing  the  riant  button  on  the 
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mouse,  and  entering  the  name  of  the  pointer  with  the 
Keyset. 

When  a  pointer  has  oeen  specified,  the  associated 
T-pointer  is  simply  loaded  into  the  internal  register 
containing  the  (processed)  mouse  location,  making  it 
appear  as  thouch  a  bug  selection  had  been  made. 

A  statement  may  be  selected  from  the  Keyboard  by  typing 
either  the  statement  name  or  the  statement  number. 

A  statement  number  is  c  inverted  into  a  PSID  for  a 
T-pointer  by  simply  running  through  the  ring  at  each 
level  (beginning  with  level  1)  u.v,il  the  specified 
statement  is  reached,  or  found  to  be  non-existent. 

A  statement  name  is  converted  into  a  T-pointer  by  running 
through  the  ring,  looking  for  a  st&temnt  which  has  a 
name,  and  whose  hash  is  the  same  as  tr.e  hash  of  the  name 
being  searched  for. 

in  the  case  where  an  operand  is  a  textual  entity  which  is 
entered  from  the  Keyboard,  there  need  not  be  an  entry  on  the 
specification  stack  for  it. 

pather,  it  will  go  directly  into  a  specifx.'d  register, 
and  be  used  in  that  form  for  the  command. 

It  should  be  noted  that  the  selections  of  textual 
entities  in  the  file  arc  processed  during  execution  of 
the  command  so  that  (when  appropriate)  the  textual  entity 
i*  put  into  a  register  in  the  same  form  it  would  be  in  if 
it  had  been  entered  from  ;  Keyboard. 

7.  Subroutine  Calls  and  Parameter  Passing 

The  subroutine  call  mechanism  in  the  SPL  is  very  similar  to 
that  used  by  ALGOL.  It  uses  a  stajk  for  containing  return 
information,  parameters,  and  local  variables. 

Because  of  the  overlay  structure  of  Nis,  it  is  necessary 
to  indicate  in  a  subroutine  call  not  only  the  address  of 
the  routine  being  called,  but  additionally  the  name  of 
the  overlay  In  which  that  routine  resides. 

The  name  of  the  overlay  containing  the  calling  routine 
is  stacked  with  the  return  location,  so  that  the 
appropriate  overlay  may  be  relabeled  in  upon  return. 
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There  are  two  type*  of  subroutine  call*,  which  differ  in 
tne  return  locations  placed  on  the  stack. 

The  return  location  stacked  oy  a  normal  auDroutine 
call  la  tne  address  of  the  location  following  the 
calling  instruction. 

The  other  subroutine  call  stacks  the  return  location 
of  code  which  will  return  NLS  to  the  previous  command 
state. 

The  format  and  operation  of  the  stack  (and  suoroutine 
call  mechanism)  are  roughly  at  follows: 

The  stack  is  addressed  py  two  pointers,  one  to  the 
current  base  and  one  to  the  stack  top. 

A  suoroutine  call  instruction  is  always  preceded  by  a 
"mark  stack"  instruction. 

The  "mark  stack"  instruction  pushes  the  contents  of 
the  base-of-stack  pointer  onto  the  top  of  the 
stack,  followed  by  a  zero  (wnich  will  be  used  by 
the  actual  subroutine  call  for  the  return 

location) . 

% 

The  top-of-stack  pointer  is  incremented 
accordingly,  and  the  base-of-stack  pointer  is  set 
to  point  to  the  new  top  of  the  stack  (wnicn  will 
eventually  contain  tne  return  location). 

Formal  Parameters  are  now  loaded  onto  the  top  of  tne 

stack. 

If  an  overlay  has  Seen  specified  in  the  subroutine 
call  syntax,  a  cell  is  set  to  reflect  the  overlay 
containing  the  procedure  being  called. 

Note  that  the  actual  program  relabeling  is  not 
changed  at  this  tiraeI 

The  subroutine  call  is  now  executed* 

The  return  location  is  computed. 

This  is  a  combination  of  the  calling  address  and 
the  name  of  the  overlay  containing  the 
subroutine  call  instruction. 
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This  is  true  except  in  tr.e  case  of  the 
special  subroutine  call  which  returns  tc  the 
previous  command  state. 

In  the  special  subroutine  call,  the  contents 
of  the  state  variable  (which  in  fact  is  the 
return  location  for  the  previous  state,  as 
computed  above)  are  used  as  a  return 
location. 

The  return  location  is  stored  in  the  ceil 
pointed  tc  by  the  b*»e-of-atack  pointer. 

Finally,  the  overlay  containing  tne  called 
procedure  is  relabeled  in  if  necessary,  and  a 
branch  is  made  to  the  address  indicated  In  the 
subroutine  call. 

The  syntax  of  a  subroutine  call  in  the  SPL  Is 

/  h.m)  procedure-name  C,"  overlay-name  /  EMPTY), 

where  "  /  EMPTY"  means  tne  construct  before  the  slash  is 
optional. 

in  addition,  parameters  may  be  specified  by  listing  them  in 
square  brackets  after  the  call.  Individual  parameters  in 
the  parameter  list  are  separated  sy  commas. 

The  indicates  a  normal  subroutine  call,  and  a 
indicates  e  special  subroutine  call  which  returns  to  the 
previous  command  state. 

If  no  overlay  name  is  specified,  an  overlay  which  is  either 
the  overlay  containing  the  calling  procedure  or  an  overlay 
above  it  in  the  overlay  tree  is  assumed,  and  thus  no  chance 
is  made  in  the  relabeling. 

An  example  of  a  subroutine  call  is 

♦  subpat  ♦war2,  txtedt/’bl,  pl-uy  -qdv,txteat. 

6.  input  Machinery 

a.  Work  station  Input  from  Keyboard,  Kevset,  and  Mouse 

Characters  are  read  from  the  work  station  by  a  system 
routine  in  the  following  manner: 
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Whenever  a  button  on  the  keyboard.  Keyset.,  or  mouse 
changes  state,  the  TSS  I/O  software  considers  it  a 
character  entry,  ana  place?  the  following  information 
into  its  input  puffer. 

(1)  The  device  which  caused  incut 

(2)  A  code  wnich  is  the  input  itself: 

(a)  A  character  in  tne  case  of  tne  keyboard 

(b)  A  code  in  the  case  of  the  keyset 

(c)  A  down/up  and  button  indication  in  the  case 

of  the  mouse 

(3)  The  mouse  coordinates  at  tne  time  tne 
character  was  read 

(4)  The  time  (16  millisecond  resolution)  when  the 
character  was  read. 

A  system  call  is  tnen  used  by  NLS  for  reading  tne 
characters  from  tne  system  input  buffer,  which  returns  a 
character  (and  related  information  as  described  above)  if 
there  is  one,  and  reports  the  status  of  the  system  incut 
buffer  (empty,  another  character  waiting  m  input  buffer, 
no  character  read) « 

b.  Input  fork 

Because  of  the  necessity  tc  read  characters  from  the 
system  input  buffer  so  that  it  does  not  overflow  -•  and 
more  important,  to  provide  a  facility  to  interrupt  nls 
while  it  is  executing  a  long  process  -•»  a  for k  is 
activated  to  run  asynchronously  in  parallel  with  nls. 

This  fork  may  be  conceptualized  as  an  independent  program 
(called  the  input  forki  which  reads  characters  from  tne 
work  station  and  places  them  in  a  programmatic  incut 
buffer  to  be  read  later  by  NLS. 

NLS  always  reads  characters  from  the  programmatic 
input  puffer  before  reading  them  from  the  system,  and 
when  it  is  reading  a  character  from  the  system,  it 
cheeKs  to  ascertain  that  the  input  fork  is  not  reading 
the  same  character. 
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Tfti  input  fork  additionally  has  the  capability  to 
interrupt  NLS  from  the  process  it  ia  currently  involved 
in,  and  it  does  so  when  it  reaas  an  interrupt  cnaracter 
(RUBOUT)  from  the  Keyboard, 

Since  NLS  always  reads  characters  passed  to  it  from  trie 
input  fork  Dsfore  reading  those  waiting  in  the  syaten, 
and  there  is  no  restriction  on  where  tne  input  fork  gets 
the  characters  it  will  pass  to  NLS,  the  input  fork  nay  oe 
used  to  simulate  an  NLS  user. 

A  simple  facility  is  currently  provided  along  this 
line,  whereby  the  input  forx  can  road  characters  from 
a  file,  and  (with  a  minimum  of  translation  and 
interpretation)  pass  them  on  NLS. 

This  feature  is  used  mostly  for  merging  and 
converting  sequential  files  into  NLS  files. 

c.  Character  Translation 

The  Keyset  and  mouse  input  requires  translation  from  its 
raw  input  form  to  a  character  which  is  meaningful  to  NLS, 

The  Keyset  input  is  in  the  form  of  a  number  (0-31) 
which  reflects  the  keys  depressed  (and  released)  on 
the  Keyset, 

This  is  combined  vitn  the  current  state  of  the  left 
and  middle  mouse  buttons  (which  provide  a  case  shift) 
to  produce  the  translated  character. 

The  translation  algorithm  is  roughly  as  follows! 

If  both  mouse  buttons  are  down  (case  y,  then  this 
is  a  view  specification  character,  so  treat 
specially. 

Otherwise,  use  the  keyset  character  as  an  index 
into  a  table  of  character  values. 

This  tabic  of  character  values  has  three  entries 
for  each  possible  keyset  value:  one  for  each  of 
the  remaining  cases. 

The  case  is  then  used  to  determine  the  correct 
table  entry  as  the  translated  character. 
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Additional  translation  is  done  when  characters  are 
entered  from  the  mouse  without  concurrent  entry  from  the 
keyboard  or  keyset. 

This  translation  simply  look*  for  combinations  of 
up/down  strokes  of  mouse  buttons  without  intervening 
characters,  and  translates  them  to  specific 
characters . 

This  is  used  for  the  command  accept,  command  delete, 
backspace  character,  and  backspace  word  characters, 

9.  Output  (Display)  Machinery 

a.  General 

NLS  communicates  with  the  user  via  a  dioulay  screen 
divided  into  six  areas. 

Each  area  is  maintained  separately  of  the  others,  and 
contains  a  specific  type  of  information. 

The  organisation  of  the  registers  on  the  display  screen, 
and  the  format  of  the  registers  themselves,  are 
parameterized. 

There  are  many  parameters  wnich  relate  specifically  to 
certain  registers,  and  some  parameters  which  relate  to 
all  registers.  Among  the  parameters  relevant  to  all 
of  tne  registers  are: 

location  on  screen 

character  size  and  type  used  in  register 
display  of  register  on/off 

Insofar  as  possible,  these  parameters  are  the  display 
control  words  used  by  the  hardware,  Tnis  minimizes 
the  software  required  for  controlling  the  screen 
format. 

b,  view  Areas 

(1)  Echo  Register 

The  echo  register  is  maintained  by  the  syjtew  and 
reflects  the  raw  character  input  to  nls. 
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NIS  ia  concerned  with  this  register  mainly  at 
initialization ,  when  it  munt  be  set  up  by  a  series  of 
system  calls* 

(2}  VIEW3PEC  Area 

The  view  specification  (VIEVSPEC)  area  reflects  thooc 
text  area  ”iew  parameters  which  are  not  obvious  from 
looking  at  the  text  area. 

The  VIEWSPEC  area  is  changed  by  the  same  routine  wnicn 
changes  the  view  parameters  themselves. 

(3)  Command  Feedback  Line 

The  command  feedback  line  ia  the  major  feedback 
mechanism  of  the  command  specification  machine. 

There  are  two  components  in  the  command  feedback  line? 
words  which  reflect  in  English  the  command  being 
specified,  and  an  arrow  which  indicates  the  user’s 
state  in  specifying  the  command  (the  arrow  most 
commonly  indicates  whether  the  user  may  specify  a  new 
command  or  parameters,  or  whether  he  is  currently 
specifying  an  entity). 

There  are  three  possible  positions  to  wnich  a  word  may 
be  moved  in  the  command  feedback  line: 

First  position:  This  causes  the  command  feedback 
line  to  be  cleared,  and  the  designated  word  to  be 
displayed  as  the  first  word  in  the  line. 

Next  position:  This  appends  the  designated  word  to 
the  end  of  the  command  feedback  line. 

Last  position:  This  replaces  the  last  word  in  the 
command  feedoack  line  with  the  designated  word. 

The  arrow  may  oe  pointed  to  the  beginning  of  the  word 
in  a  specified  position  in  the  command  feedback  line, 
or  it  may  be  turned  off. 

The  SPL  construct  provided  for  the  manipulation  of  the 
command  feedack  line  ia 

MD3P ( H  display-parts  *)”, 
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where  the  syntax  of  a  display-oart  ia 

word  /  "ES*"  /  *<*  word  /  word  /  "*■"  /  ••  t". 

The  DSP  command  rearranges  the  command  feedback  line 
so  that  it  ia  formatted  in  accordance  with  the 
diaplay-parti. 

The  meaning*  of  the  display  parts  are  as  follows* 

Word;  A  string  equal  to  the  text  of  tne  the  word  i* 
placed  in  the  indicated  position  in  the  command 
feedback  line 

*  ES*"  i  The  contents  of  the  entity  strip.?;  are 
displayed  in  the  indicated  position  in  tne  command 
feedback  line 

"<H  word*  The  word  is  placed  at  the  left  ef  the 
command  feedback  line 

word:  Replace  the  last  string  in  the  current 
command  feedback  line  with  the  word 

;  Position  the  up-arrov  to  the  front  of  the 
command  feedback  line. 

"t"  t  position  the  up«arrow  at  the  start  of  the 
following  string  in  the  command  feedback  line. 

There  are  three  additional  intrinsic  functions  which 
are  used  in  relation  to  the  command  feedback  line. 
These  are 

X?  Turn  off  display  of  arrow 

AN  Turn  on  the  display  of  the  arrow 

QM  Display  question  mark  beside  the  arrow, 

U)  Name  Register 

The  name  register  is  used  for  displaying  statement 
names  and  arbitrary  strings  relating  to  parameter 
specification. 

An  3PL  function  if  provided  which  move*  the  content* 
of  an  arbitrary  string  regiiter  to  the  name  register. 
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The  syntax  is  "DN(m  register  ")" . 

(5)  Date/Tine  Register 

The  date/time  register  always  reflects  the  date  and 
tine. 

It  is  updated  every  10  seconds  by  a  forx  {similar  to 
the  input  forx  in  it*  relation  with  NLS)  whose  sole 
4ob  is  to  read  the  date  and  time  from  the  system, 
place  it  in  a  core  location,  and  dismiss  itself  for  i.0 
seconds. 

(6)  Text  Area 

The  text  area  serves  as  the  user's  window  into  his 
file. 

What  is  displayed  in  the  text  area  is  a  view  of  the 
user’s  file,  subject  to  certain  formats  and 
reorganisation,  which  is  described  by  a  set  of 
parameter#  (called  view  specifications  or 
VIEWSPECs) « 

The  creation  of  new  views  is  programmatically  caused 
by  the  display  3PL  construct  "display {" 
optional-parameter  ••)*. 

If  there  is  a  parameter,  it  is  used  to  determine 
the  PSID  of  the  starting  statement  for  the  view 
creation. 

The  process  of  creating  a  view  of  the  file  in  the  text 
area  is  discussed  in  Sec.  IV-R-6  of  this  appendix. 

c.  Literal  Feedback 

When  a  literal  string  is  entered  as  a  part  of  parameter 
specification,  it  is  placed  in  the  text  area  (beginning 
at  the  top)  according  to  the  format  of  the  text  area. 

The  part  of  the  file  view  whi^h  was  previously  In  the 
space  used  oy  the  literal  feedback  is  temporarily 
replaced  by  the  feedback. 

B.  Command  specification  in  T0DA3 

The  TODAS  command  specification  system  is  much  simpler  than 
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that  ci  NLS,  insofar  as  it  does  not  use  tne  state  nacnlne  and 
no  command  state  is  defined  other  than  the  null  command  RESET, 

1.  Command  Feedback 

The  command  language  input  string  is  parsed  o y  case 
statements  in  a  manner  similar  to  NLS. 

The  command  feedback  may  best  be  described  as  complex 
character  echoing,  where  each  command  specification 
character  is  reflected  by  the  typing  of  appropriate  words 
and  the  state  of  tne  command  specification  is  indicated  by 
the  position  of  the  carriage. 

As  in  NLS,  the  user  has  tne  aoility  to  control  parameters 
relating  to  the  command  feedback,  including  the  nunoer  of 
characters  of  each  word  echoed, 

2,  input  Machinery 

Much  of  the  .iLS  input  machinery  is  used  by  TODAS, 

There  are,  however,  some  differences: 

because  of  the  allowance  which  the  system  maxes  for  an 
interrupt  character  (RUBOUT),  ana  tne  feet  that  the 
system  teletype  buffers  are  larger  than  the  system  work 
station  buffers,  an  input  fork  is  not  required. 

One  may  still  be  used,  however,  in  special  cases  such 
ac  sequential  file  input. 

All  characters  read  by  TODAS  undergo  a  translation  on 
input. 

This  facilitates  the  effective  interfacing  of  TODAS  to 
a  number  of  input  devices  (six  different  types  of 
typewriter  terminals  are  currently  provided  for). 

The  cnjracter  translation  is  accomplished  by  a 
table  look-up  technique  (the  table  is  indexed  by 
the  raw  character  value). 

The  result  of  the  look-up  may  be  a  normal  text 
character,  or  it  may  be  a  special  character  (which 
is  indicated  by  the  high-order  bit), 

in  the  event  that  It  is  a  special  character 
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(command  accept,  command  delete,  shift  character, 
centerdot,  etc.),  an  appropriate  action  is  t a e n  if 
necessary.  The  character  may  he  ecnoed  (as  some 
previously  designated  character),  and  it  may  he 
specially  flagged  as  a  control  character. 

There  is,  in  addition  to  straight  character 
translation,  a  facility  to  define  shift  characters 
which  allow  devices  vitn  restricted  character  sets 
(e.f.  upper  case  only)  to  work  with  full  character 
sets. 

Four  shift  modes  are  currently  defined  in  TODAS: 

Null *  No  shifting  taxes  place 

Mode  Oi  upper-case  alphabetic  characters  are 
translated  to  lower  case 

Mode  1:  Lower-case  alphaoetic  characters  are 
translates  to  upper  case 

Mode  2:  Lower-  and  upper-case  alphabetic 
characters  are  translated  10  control  case 

TODAS  is  in  one  of  these  modes  (as  a  case  mode)  at 
all  times. 

The  mode  may  be  changed  (eitner  temporarily  or 
permanently)  by  typing  a  character  which  has  been 
defined  as  a  shift  character  for  the  new  mode. 

There  are  currently  three  types  of  mode-shifting 
characters  * 

Character  shift!  This  causes  the  following 
character  to  be  transacted  according  to  the 
node  for  wnich  the  shift  character  has  been 
defined,  if  it  is  a  character  which  would 
normally  have  been  translated  in  either  trs 
base  node  or  tae  shift  mode.  If  the 
character  would  not  have  been  translated, 
then  the  shift  character  is  treated  as  a 
normal  character. 

Word  shift*  This  causes  the  following  word 
to  be  translated  subject  to  tne  same  rule  as 
given  above  for  character  shift  --  i.e.,  if 
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the  next  character  ii  translatable,  the  word 
is  traslated;  otherwise  th  shift  character  is 
treated  as  a  normal  character. 

Permanent  shift:  This  causes  the  base  node 
to  be  chanced,  and  all  subsequent  characters 
are  translated  according  to  tne  new  node. 

The  shifting  ia  accomplished  in  the  following 
manner i 

If,  a  permanent  snift  character  is  read  at  any 
tine,  the  shift  node  is  changed  ana  another 
c  racter  is  road  nornallv. 

If  a  word-shift  or  character-snif t  character  is 
read,  the  next  character  is  retd  fron  the  input 
string , 

If  tne  next  character  is  a  shiftable 
character,  then  the  shifting  is  performed, 
and  the  shifted  character  is  tne  result. 

If  the  shift  character  is  for  a  word 
shift,  then  a  global  parameter  indicating 
the  current  shift  state  is  set 
accordingly,  and  will  not  oe  reset  until  a 
space  is  read. 

If  the  next  character  is  not  a  shift 
character,  it  is  returned  to  the  front  of  tne 
input  string  and  the  shift  character  is 
returned  as  a  normal  character. 

3.  Printing 

printing  of  a  structure  in  T0DA3  is  analogous  to  creating  a 
new  view  for  the  text  at ea  in  NLS,  insofar  as  the  same  view 
specifications  are  used  for  interpreting  and  formatting  the 
file. 

Three  d^f-ere^cea  are  apparent: 

The  text  area  is  of  unlimited  length,  so  that  a  whole 
file  may  be  seen  in  one  view,  pagination  is  performed 
when  a  long  view  ’  -  created. 

Text  undergoes  an  output  translation  and  shifting 
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which  if  «.  counterpart  of  the  translation  and  shifting 
done  on  input. 

The  uier  ha*  a  degree  of  interactive  control  over  the 
view  being  creates,  specifically i 

The  creation  of  a  view  of  any  particular  statement 
nav  be  aborted  at  any  time. 

The  creation  of  the  entire  view  may  be  aborted  *t 
any  tine. 

Xmplementationally,  formatting  routines  different  from 
those  used  by  NLS  are  employed. 

The  output  is  foraatt"  #ne  line  a:-  a  time,  and  the 
printing  of  an  entire  statement  must  physically  finish 
before  the  first  line  of  the  next  statement  will  be 
printed. 

This  restriction  is  necessary  because  TODAS  must, 
Know  which  statement  is  currently  being  typed  in 
order  to  respond  properly  to  the  user’s  request  to 
abort  the  view  of  the  statement. 

The  same  sequence  generator  ia  used,  but  the  structure 
being  printed  is  searched  one  branch  at  a  tine  (except 
in  the  case  of  trails  and  Keyword). 

k.  Parameter  Specification 

Parameter  specification  differs  from  NLS  in  three  important 
ways! 

All  specification  must  be  done  via  the  Keyboard. 

A  "current  statement"  ia  defined  as  an  operand  at  all 
times. 

The  execution  of  any  command  without  a  specified 
operand  assumes  this  statement  as  an  operand. 

The  current  statement  is  represented  internally  as  a 
cell  containing  the  PS  ID  of  the  last  statement 
addressed  in  the  succeosful  execution  of  a  command. 

It  is  updated  each  timh  a  command  is  successfully 
executed. 
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The  one  exception  to  tnis  la  that  during  printing, 
it  is  set  oy  the  print  routines  to  tne  psiu  of  tne 
last  statement  printed. 

Operands  (statements)  nay  0e  addressed  relative  to  each 
other  in  the  tree  structure  of  the  file. 

For  example.-  one  may  specify  a  statement  which  is  the 
"successor  of  tne  down  of  tne  tail"  of  tne  current 
statement  --  i.e.,  tne  successor  of  the  first 
suostatement  of  the  last  statement  in  the  same  plex  at 
the  same  level  as  tne  current  statement. 

Tne  relative  addresses  of  operands  are  interpreted  as 
they  are  entered  by  accessing  the  ring  (as  necessary). 
Any  error  is  reported  immediately,  and  nullifies  the 
entire  address  (except  in  the  case  of  iMKs). 

'  *>nxs  are  parsed  whenever  they  are  referenced  in  an 
address  fie*d,  and  executed  immediately  after 
selection,.  That  is  to  say,  wnen  a  lime  is 
encountered  in  an  address  field,  the  current 
statement-  is  changed  immediately  to  reflect  tne 
value  indicated  oy  the  3  in*. 
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A »  Editing 

Editing  in  MLS  includes  textual,  structural,  and  graphical 
modifications  to  the  file. 

The  textual  and  structural  editing  actions  include  insert, 
move,  replace,  delete,  and  copy.  These  actions  may  be 
performed  on  textual  entities  sucn  as  characters,  words,  and 
visible  strings,  as  well  as  structural  entitiec  such  as 
statements,  branches,  groups,  ana  plexes. 

The  graphical  editing  actions  include  insert  and  delete  for 
vector  labels,  and  insert,  delete,  move,  transpose,  and 
vertical  and  horizontal  projection  fen  vectors, 

1.  Text  Editing 

a.  General  Considerations 

The  process  of  textual  editing  will  be  discussed  first, 
Thu  process  basically  consists  of  delimiting  the 
appropriate  substrings,  by  means  of  the  content-analysis 
SPL,  followed  by  construction  of  one  or  more  new 
statements  with  the  desired  modifications.  This  latter 
step  it  specified  by  a  procedure  written  in  another  3PL, 
the  string-construction  3PL. 

These  content-analysis  and  string-construction  procedures 
art  written  in  such  a  way  that  in  epite  of  the  large 
number  of  combinations  of  editing  actions  and  textual 
entities,  there  la  a  single  content-analysis  procedure  to 
delimit  each  entity  and  a  single  string-construction 
routine  to  perform  each  action. 

Tnia  is  done  by  standardizing  the  way  in  which  a 
substring  is  delimited  by  the  content-analysis 
procedures. 

Four  pointers  are  passed  to  the  procedure  as 
arguments,  along  with  one  or  two  selections  made  by 
the  user. 

When  the  procedure  returns,  the  appropriate  substring 
is  delimited  by  the  pointers  in  the  following  ranner. 

The  first  and  second  pointers  nark  the  first  - r.u 
last  characters  of  the  substring,  respectively. 

The  third  and  fourth  pointers  r*rk  the  characters 
to  the  left  and  right  of  the  subatring, 
respectively. 
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Thus  if  PI,  F2,  F3»  and  PL  are  the  arguments,  the 
characters  from  the  front  of  the  statement  up  to  P3 
precede  the  desired  substring,  the  characters  from 
PI  to  P2  are  the  substring,  and  those  from  PL  to 
the  end  of  the  statement  follow  the  substring. 

A  detailed  description  of  the  word-delimiter  routine  is 
ureful  to  clarify  this  process. 

There  are  five  arguments;  the  first  is  the  position  oi 
the  user's  selection,  the  remaining  are  pointers  to  oe 
used  to  delimit  the  actual  text  ol  the  word  in  tne 
manner  described  above.  The  body  of  tne  procedure  is 
simply 

al  >  CH  »LD  ta3  ?*5  **3  al  <  CH  ILL  taii  tau  *a2 

which  has  the  meaning  “starting  from  tne  selection 
(al)  scan  to  the  right  (>)  past  a  character  iCH)  and 
any  number  of  letters  or  digits  (ALD).  Set  a3  and  a5 
to  tne  resulting  position  (ra3  raS)  then  move  a3  back 
(♦■43)  so  that  it  points  to  the  last  character  of  the 
word.  Nov  reset  the  search  pointer  to  the  selection 
(al)  and  scan  to  the  left  (<)  to  set  a2  and  au  (ta2 
tali  4-42) . " 

once  the  substrings  have  been  delimited  in  the  above 
manner,  new  statements  are  constructed  under  the  control 
of  procedures  written  in  the  string-construction  SPI, 

The  syntax  of  a  statement  in  tne  string-construction  SPL 
is  as  follows ; 

acstat  «  "IF*  poarelation  "THEN"  scstat  "ELSE"  acstat 
/ 

” dEGIN"  scstat  !(";*  acstat)  " F- N D "  / 

"ST"  ro«  pairiist; 

The  position  and  posits ot. -relation  constructs  are  the 
same  as  in  tne  content-analysis  SPL. 

A  pairiist  is  a  list  of  pairs,  in  this  case  separated  by 
commas . 

A  "pair"  specifies  a  string  of  text,  usually  by  giving 
two  positions  which  delimit  the  string. 
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In  Addition  the  "pair"  can  be  a  constant  etrin*  or  the 
contents  of  some  variable  string  such  as  the  literal 
input  register. 

The  meaning  of  "ST  poa  *■  pairliat”  is  "The  statement 
pointed  to  oy  poa  is  constructed  fror.  the  strings 
specified  by  the  items  in  the  pairlist." 

Thus,  assuming  that  the  pointers  have  been  set  as 
described  above,  HST  bl  *  SHB.1)  P3i  Pi  SE(B1)"  would 
cause  the  text  from  pi  to  P2  to  be  deleted  from  the 
statement  selected  Dy  01. 

The  "move"  procedure  offers  a  more  complex  examole,  The 
procedure  has  ten  arguments*  al  and  a2  are  tne  user's 
selections,  a3  through  a6  are  the  pointers  associated 
with  al,  and  a7  through  alO  are  the  pointers  for  a2.  The 
body  of  the  move  routine  is 

IF  3FU1)  *  SFU2)  THEN  BEGIN 
IF  al  <  A2  THEN 

ST  al  *  SFU1)  ak,  a?  aft,  a6  a9,  alO  SE{al) 

ELSE 

3T  al  >  SK(al)  *9,  alO  a k,  a7  ad,  a6  SE(al)  END 
ELSE  BEGIN 

ST  al  ♦»  S  F  ( a  ?„ }  ak,  47  ad,  a6  SE(al); 

ST  ^2  *■  SF{42)  a9,  HO  SE(a2)  En’D 

Tne  pair  a7  ab  delimit*  the  text  to  be  moved.  Tne 
positions  a9  alO  vill  Decone  adjacent  wnen  the  text 
from  a7  to  ab  is  moved.  The  destination  of  the  text 
between  a?  and  ab  is  after  ih  and  before  a6.  Tne  reader 
Should  convince  himself  that  the  accve  procedure  does 
this  in  all  cases. 

b.  implementation 

The  code  compiled  for  string-cons truction  SPL  routines 
consists  mainly  of  calls  to  MOL  procedures. 

At  the  start  of  the  code  for  a  pairlist  there  is  ■  call 
to  &  procedure  called  BSC  ibegin  string  construction)  and 
at  the  end  of  the  pair  list  there  is  a  call  to  ESC  (end 
string  construction).  For  the  actual  items  in  the 
pairlist,  procedures  are  callec  which  append  the 
appropriate  strings  onto  the  statement  being  constructed. 

The  BSC  procedure  must  create  a  nt.r  statement  data  blocx 
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(SDB)  to  hold  the  text  f  f  tne  statement  beim 
constructed.  Since  tne  final  site  of  the  statement  is 
not  Known  at  the  time  BSC  is  called,  tne  average  size  of 
SD5s  in  the  file  is  used  as  an  estimate  of  the  number  of 
words  required  for  the  new  SDB. 

The  search  for  the  required  amount  of  room  Degins  in 
the  file  block  containing  the  old  SDB,  if  there  was 
one. 

If  there  is  not  adequate  room  there,  then  tne 
procedure  Iooks  for  room  in  the  file  dIocks,  starting 
with  the  lowest  index  number. 

This  ensures  that  if  there  is  room  in  a  ciocK 
already  allocated,  then  that  room  will  be  used 
rather  than  causing  a  new  blocx  to  oe  allocated. 

The  procedure  ISROOM  is  called  to  determine  whetner 
there  is  adequate  room  m  a  given  file  block. 

If  the  block  is  unallocated,  then  ISKOOrt  returns 
TRUE  • 

If  tne  block  is  allocated  and  contains  adequate 
free  storage,  then  such  information  is  held  in  the 
status  table,  RFbS.  This  avoids  the  possibility  of 
reading  a  file  block  only  to  find  tnat  it  does  not 
contain  adequate  room. 

If  the  block  does  not  contain  adequate  free 
storage,  but  does  contain  garbage  SDBa  (also  known 
from  RFBS } ,  then  ISROOM  calls  the  garoaee  collector 
to  process  the  clock. 

Garoage  collection  involvgg  moving  nongarbage 
SDBa  to  fill  in  the  gaps  occupied  oy  garbage 
5DB8  and  updating  pointer*  in  the  ring  elements 
corresponding  to  the  moved  SDEs. 

I  this  produces  enough  room,  then  ISROOM  returns 
TRUE;  otherwise  it  returns  FALSE. 

After  sufficient  room  has  been  found  by  the  above 
process,  the  BSC  procedure  *uilds  a  header  for  tne  new 
SDB  and  then  sets  up  a  work  area  for  the  subsequent 
string  transfers  that  will  take  place  during  the 
construction  of  the  statement.  This  work  area 
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contains  information  such  as  tne  address  of  the  SDH. 
This  completes  the  tasks  of  BSC ,  and  it  returns. 

The  actual  construction  of  the  new  statement  consists  of 
appending  characters  onto  the  new  SDB. 

For  those  parts  of  the  statement  that  remain  the  same, 
the  text  is  read  out  of  the  old  SDB  into  the  new.  New 
parts  of  the  statement  are  s imply  characters  from 
other  sources,  such  as  literal  input  or  other  5DBa. 

The  observant  reader  will  realize  that  it  is  possible 
to  run  out  of  room  while  appending  characters. 

If  this  happens,  the  block  is  garbage-collected. 

If  this  results  in  room  for  at  least  60  more 
characters,  then  the  SDB  under  construction  is 
simply  moved  in  with  the  same  file  Dlock  to  make 
more  rcom. 

If  garbage  collection  of  the  file  block  cannot 
produce  that  much  more  room,  a  location  in  t 
different  file  block  io  found  that  does  provide  the 
required  space.  The  partially  constructed  SDB  is 
then  moved  to  this  new  location. 

wnen  all  the  strings  ha\  been  appended  to  the  SD3,  the 
procedure  eso  is  called  o  finish  the  job. 

It  first  gets  rid  of  the  old  SDB  for  the  statement, 
then  does  the  bookkeeping  to  estaolisn  tne  new  SDB  ac 
the  SDB  for  the  statement.  This  involves  updating  the 
SDB  header,  the  running  average  length  of  SDB’s,  tne 
pointer  in  the  statement’s  ring  element,  and  the  name 
hash  for  the  statement  in  the  ring  element . 

in  addition  the  "content  analyzer  pattern  tested"  flag 
for  the  statement  is  turned  off  (see  Sec.  ll-B-2-c  of 
this  appendix) . 

This  completes  the  construction  of  a  new  statement  and 
our  discussion  of  text  editing  in  NLS, 

c.  Content-Analysis  SPL 

In  NLS  it  is  often  necessary  to  analyze  tne  textual 
content  of  a  statement  in  order  to  delimit  certain 
substrings. 
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For  example,  the  user  may  select  a  word  of  text  for 
editing  oy  pointing  to  any  character  witnin  the  word, 
Tne  actual  substring  making  up  tne  word  is  determined 
by  NLS. 

A  special  language,  the  content-analysis  SPL,  is  jsed 
writing  *uch  string  delimiting  procedures. 

basically,  the  Jansuage  provides  constructs  for 
controlling  the  position  of  a  search  pointer  in  a  text 
string  and  saving  various  positions  in  order  to  delimit 
the  desired  suDStringr,  (in  the  discussion  of  the 
content  analysis  SPL,  position  refers  to  a  statement, 
identifier  and  character  number  --  in  other  words,  a 
T-pointer  as  defined  elsewhere,} 

The  initial  position  of  the  search  pointer  is  often 
determined  by  a  selection  made  by  the  user.  The 
poaitiors  of  sucn  selections  are  stored  in  buffers  31, 
E2,  etc. 

pointers  pi,  P2,  ...  may  De  used  to  store  positions.  Th 
current  position  of  the  search  pointer  car,  De  stored  in 
Pn  by  writing  tPn. 

Arguments  may  be  passed  to  a  content  analysis  procedure. 
Such  arguments  are  either  bug  selections  (i.e.  bn)  or 
pointers  (i.e.  pn) ,  Since  the  procedure  must  be  able  to 
set  the  pointers  to  appropriate  values,  tnese  parameters 
are  called  by  (simple)  name  rather  than  by  value.  The 
formal  parameters  are  Al,  A2,  etc. 

The  three  forms.  Bn,  pn,  and  An,  are  the  basic  ways  of 
referencing  a  position.  In  addition,  there  are  two 
functions  taking  a  position  ae  argument  and  yielding  a 
position  as  result.  These  are  SF  and  SE,  which  give  the 
position  of  the  statement  front  and  statement  end, 
respectively,  of  their  argument. 

The  position  of  the  search  pointer  can  be  set  by  simply 
writing  any  of  tne  above  forme  to  determine  a  position. 
For  example,  ’’SFlBl)"  puts  the  search  pointer  at  the 
first  character  in  the  statement  first  selected  by  the 
user. 

The  search  pointer  is  also  moved  by  tests  for  basic  text 
mlements.  The  basic  text  elements  are  strings,  single 
characters,  and  character  class  variables. 
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A  string  is  a  sequence  of  characters  delimited  by 
quote  marks  ( " ) .  * 

U  the  Ptrlni  matches  the  sequence  of  characters 
surtini  at  the  current  location  of  the  search 
pointer,  then  the  search  pointer  is  moved  to  the 

is*«et°T~U£0n  bey°nd  th®  s^ing  4nd  x  general  flag 


If,  or.  the  other  hand,  there  is  only  a  partial 
match,  or  no  natch*  then  the  search  pointer  is  not 
moved  and  the  general  flag  is  set  FALSE. 


The  teat  for  a  single  character  is  logica-llv 
equivalent  to  testing  for  a  string  of  length  one 
is  implemented  in  a  more  efficient  manner.  The 
character  is  specified  by  preeedirg  it  with  an 
apostrophe. 


,  but 
single 


The  implementation  of  these  teats  makes  us*  of  the 
programmed  operator  ( POP)  facility  of  the  no. 

For  the  single  character  test,  ttr  computer 

fle?.6^?  ?£;«*!  instruction  m  whicn  the  .dare., 
field  contains  the  code  for  the  character  and  the 
rest  of  the  instruction  specifies  the  POP  to 
perform  the  test. 


Similarly,  the  string  test  result  a  in  ar. 
instruction  specifying  the  number  of  characters 
the  string  and  the  appropriate  POP,  followed  by 
words  containing  the  actual  string. 


in 


The  basic  text  elements  of  the  third  type  --  the 
charter  cl,.,  variable.  -  are  ,l.e  implemented 
u.ing  t  programmed  operator.  The  character  cits, 
variables  allow  tests  for  any  character  in  a 

el*8,•  T,lc  =!»•*««.  with  their  associated 
variable  name*,  are  as  follow*! 


LD  any  letter  or  digit 

l  any  letter 

D  any  digit 

NP  any  nonprinting  character 
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PT  any  printing  character 
SP  apace 
TAB  tab 

CR  carriage  return 
CH  any  character 

These  testa  are  implemented  in  a  manner  very  similar 
to  tne  single  character  test,  except  the  address  field 
of  the  instruction  contains  a  class  code  rather  than  a 
character  code. 

The  successful  completion  of  one  of  the  above  tests 
causes  the  search  pointer  to  be  moved.  The  direction  in 
which  it  is  moved,  towards  the  end  of  the  statement  or 
tne  front,  nay  also  be  controlled. 

A  ">“  means  scan  (neve  pointer)  to  the  right,  or 
towards  the  end,  while  !'<"  means  scan  left. 

As  mentioned  above,  the  current  Position  of  the  search 
pointer  can  be  saved  by  writing  "t"  followed  by  either  Pn 
or  An, 

in  addition  the  value  stored  in  a  buffer  can  be  modified 
to  point  to  the  preceding  character,  according  to  the 
current  scan  direction,  by  writing  followed  by  pn  or 
An. 


The  reason  for  this  operation  is  that  when  an  entity 
has  been  successfully  found  the  pointer  is  left 
pointing  to  the  character  beyond  the  entity.  Thus  to 
save  the  position  of  the  last  character  in  the  entity 
it  is  necessary  to  write  tpn*pn„ 

The  remainoer  of  the  language  simply  provides  for 
building  more  complex  expressions  from  the  basic  text 
elements  presented  above. 

one  of  the  primary  means  of  doing  this  4  a  the 
arbitrary  number  operation.  Tne  genera  form  of  this 
is  mSn  followed  by  a  text  expression  a?  the 

meaning  "from  m  to  n  occurrences  of  th  >n 
expression. " 
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Both  the  upper  and  lower  counds  are  optional,  with 
default  values  of  1000  &r,  -  respectively. 

This  is  implemented  in  the  following  manner* 

The  upper  and  lower  bounas  an<*  a  count, 
initially  zero,  are  pushed  on  the  atacx.  Then 
the  test  for  the  expression  is  repeated  until  it 
fails,  with  the  count  oein?  incremented  at  the 
completion  of  each  successful  test. 

when  the  test  for  the  expression  does  fail,  the 
current  value  of  the  count  is  checked  against 
the  bounds  and  the  general  flag  set  accordingly. 

The  other  operators,  in  order  of  decreasing 
precedence,  are  as  follows! 

-  uninus  sign):  indicates  negicion. 

After  the  test  for  the  text  expression  following 
the  minus  sign,  the  value  of  the  general  flag  is 
complemented . 

(space)!  indicates  concatenation. 

After  the  test  for  each  element  in  a  sequence  of 
concatenates  tests,  the  general  flag  is  tested. 
If  it  is  false,  then  the  preceding  element  was 
not  found  and  control  branches  to  the  location 
following  the  current  sequence  of 
concatenations,  if  the  flag  is  true,  then  the 
next  test  in  the  sequence  is  performed, 

/  Ulai’*):  indicates  alternatives. 

If  the  expression  on  the  left  of  the  slash  is 
found,  then  control  oraches  beyond  the  sequence 
of  alternative i ,  otherwise,  the  search  pointer 
ia  reset  to  its  position  prior  to  the  test  for 
the  previous  alternative  end  the  next 
alternative  in  the  sequence  is  tested. 

NOT:  indicates  negation, 

Equivalent  to  minus  sign  except  for  lower 
precedence. 
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AND:  indicates  loc^cal  conjunction. 

If  the  expression  on  tne  left  of  the  and  if  rot 
found,  then  control  branches  beyond  the 
expression  on  tne  right  of  tne  and,  otherwise, 
the  search  pointe  is  reset  to  its  cosition 
prior  to  teat  £  the  left  expression  and  then 
the  rignt  expression  is  tested. 

OH:  indicates  logical  disjunction. 

Like  AND  except  branch  if  flag  true  instead  of 

falae . 

Any  expression  built  using  tne  above  operations  nay  oe 
enclosed  in  parents  ses  and  used  as  a  basic  element  m 
a  concatenation. 

Similarly,  any  such  expression  nav  be  enclosed  in 
square  brackets  and  used  as  a  basic  element.  The 
effect  of  the  square  fcracxets  is  to  "unancnor”  tne 
scan.  In  other  woraa,  ac  lcn*  as  .ne  test  fails,  it 
is  repeated  starting  one  character  farther  along  in 
the  statement  until  either  tne  statement  is  exhausted 
or  tne  test  succeeds. 

Thus  /M AhcV  is  satisfied  If  tre  remainder  of  the 
statement  contains  tne  strir-  "ibc". 

Finally,  a  conditional  statement  is  included  in  the 
language  to  allow  a  pattern  to  be  selected  for  testing 
on  the  basl^  of  a  comparison  of  positions. 

If  two  positions  are  i.i  different  statements,  then 
ail  relations  between  th..m  are  false  except  "not 
equal.”  Otherwise,  the  relationship  d-  penes  on  the 
character  number  of  the  position.  For  exartole,  if 
Si  and  52  are  in  the  same  statement,  B1  pointing  to 
character  number  3  and  B2  to  character  number  20, 
t.ien  31  is  less  than  B2. 

Thia  completee  tne  description  of  the  content-analysis 
SPL. 

2,  Structure  Editing 

Lihe  text  eoiting£  structure  editing  consists  of  a  phase  in 
which  the  entity  to  be  edited  is  ceiinitea,  followed  tne 
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actual  editing  action. 


Since  the  structural  entities  "branch”  ana  "plex"  are  aimoly 
special  cases  of  the  group  entity,  the  editing  routines  all 
deal  with  either  a  single  statement  or  a  group. 


The  delimiting  for  the  move  and  delete  eenmanaa  is  tne  same. 


in  all  cases  a  group,  speni. led  by  two  PSID's,  la  the 
final  entity  on  which  the  editing  action  is  performed. 


For  a  branch  the  two  F5ID'a  for  tne  group  are  act  to 
the  PS  ID  of  the  selected  statement. 


For  a  plex  the  PSID's  are  set  to  the  nead  and  tail  of 
the  plex  of  the  selected  statement,, 

For  a  statement,  «  test  is  made  to  ensure  that  the 
otatenent  has  no  substructure,  after  wnich  it  is 
treated  line  a  branch,  (If  the  statement  does  have 
substructure  the  command  ia  aborted,) 

Finally,  if  the  specified  entity  is  a  group,  then  the 
two  selected  statements  are  checxed  to  verify  that 
they  oo  in  fact  specify  a  valid  group. 

once  the  group  has  been  delimited,  the  move  commands  perform 
the  following  sequence  of  operations. 

first,  the  destination  is  checked  to  make  sure  ^.t  is  not 
within  the  specified  group.  The  command  is  aborted  if  it 
is. 

The  group  is  then  removed  from  the  ring  structure  by  the 
appropriate  changes  in  pointers  and  flags  in  the  ring 
flement  of  the  predecessor  (ard  possibly  the  successor) 
of  the  group.  The  group  is  then  reinserted  into  the  ring 
in  its  ntw  location  through  another  set  of  changes  in 
pointers  and  flags.  Notice  thit  no  text  is  moved  and  no 
statement  identifiers  are  changed.  The  only  changes  are 
in  the  successor  and  eubf tatsaent  fields  and  the  head  and 
tail  flags  o t  four  or  five  ring  elements. 

The  execution  of  delete  commands  naturally  results  in 
greater  changes.  The  group  is  first  removed  as  in  the  move 
operation.  Then  the  statement*  making  up  to  the  group  are 
deleted  accor^ng  to  the  following  algorithm  expressed  In 
MOL. 
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dl*grplj  fcstart  with  the  first  statement  in  tne  group* 
LOOP  BEGIN 

WHILE  (d2  -  getaub(dl))  HOT*  <11  DO  BEGIN 
*dl  has  substructure* 
atos *b (dl,dl) ;  *cnarge  sub-pointer 

so  that  <51  no  longer  apoears  to  have 
substr  'ture* 

<11  «■  <52  *nore  to  sub*  END; 

*when  exit  the  WHILE  ctatement, 

<32  equals  01  and  has  no  substructure  * 

Cl  +  getsuc(dl);  *cove  <51  to  the  successor, 
wnich  will  be  bacx  to  the  "fatner"  statement 
when  all  of  its  descendents  h.Rve  been  deleted* 
relst(<52);  i  release  SDB  for  d2* 
frersv{d2);  *  free  ring  element  for  d2* 

IF  <52  *  grp2  DO-SINGLE  RETURN  END; 

^finished  when  have  deleted  top  statenent  of  last 
branch  in  group* 

Note  that  since  tne  successor  of  the  last  statement  in  a 
plex  is  tne  fatner  of  the  plex,  no  stack  is  neeaed  in  the 
above  algorithm.  Also  note  the  manner  in  vnicn  the 
sub-pointers  are  modified  to  guide  the  traversal  of  the 
group. 

as  might  oe  expected,  copying  &  group  is  -lore  complicated 
than  deleting  o’  since  tne  structure  cannot  De  modified 
during  the  pro^, 

in  very  Jinplifiea  form,  the  copy  group  algorithm  is  i'* 
feiieve : 

Starting  at  the  first  statement  in  the  group,  if  tne 
st&ter.ent  has  substructure ,  copy  that  first;  then  copy 
tne  statement  and  move  to  its  successor  until  the  last 
statement  in  the  group  has  beer,  copied. 

when  the  group  has  been  copied,  it  is  inserted  in  the 
appropriate  position  in  tne  ring  in  the  same  manner  as  a 
group  being  moved  is  reinserted  into  the  ring. 

3 e  Graphics  Editing 

BlocKa  containing  picture  information  are  virtually 
inaentical  to  those  containing  text  information.  Tne  main 
difference  is  the  replacement  of  statement  data  blocks  by 
vector  data  blocks  ( VDB' a) . 


250 


Appendix  Dt  TECHNICAL  DESCRIPTION  Or  NL5 
See#  IV i  Command  Algorithms 


A  vector  data  b'oex  is  made  up  of  &  header  ana  an  arbitrary 
nuncer  of  lines  and  labels  maKing  up  a  picture. 

The  Reader  contains  much  the  sane  information  as  is  held  in 
the  header  of  an  SDb.  instead  of  character  counts,  however, 
the  VD3  header  contains  a  count  of  the  number  of  lines  in 
the  picturet 

Following  the  header  is  a  sequence  of  two-word  buffers,  each 
representini  a  line  in  the  picture. 

The  first  word  gi/es  the  petition  c t  o no  end  cf  the  line 
relative  to  the  lover  left-hand  corner  of  the  text  of  the 
statement# 

The  second  word  gives  the  position  of  the  second  end  of 
the  line  relative  to  the  first  endpoint. 

Following  uhe  puffers  for  the  lines,  ecch  label  in  the 
picture  is  otored  as  a  position  (in  the  tame  format  as  the 
first  word  of  a  line  buffer)  and  a  text  string. 

The  current  vector  package  was  developed  on  a  trial  basis 
with  a  relatively  small  programming  investment,  as  a  result 
of  this,  the  only  graphic  entities  available  are  lires 
(vectors)  and  labels,  a  more  sophisticated  graphics  system 
has  been  designed  but  not  yet  implemented. 

Selection  of  these  entities  is  handled  in  the  following 
manner. 

Line  selection  ic  aone  by  finding  the  line  that  minimizes 
the  difference  between  the  sum  of  the  squares  of  the 
distances  from  the  endpoints  of  the  line  to  the  tug 
selection  and  the  square  of  tae  length  of  the  line. 

This  is  a  practical  algorithm  since  the  nunter  of 
lines  involved  is  email  (under  100). 

Label  selection  is  done  by  finding  the  label  that 
cinimlieo  the  square  of  the  distance  between  the  bug 
selection  and  the  second  character  of  the  label. 

The  "move  vector"  command  will  be  explained  as  an  example  of 
vector  editing. 

This  command  allows  the  user  to  Hove  one  end  of  a  line  to 
a  new  position. 
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when  the  line  is  selected,  the  end  that  is  closer  to  the 
selection  is  offered  as  the  end  to  oe  moved.  The  user 
nay  request  to  nove  tne  other  end  instead  oy  entering  a 
backspace  character. 

The  next  selection  by  the  user  specifies  tne  ne«  location 
for  the  end  which  is  tc  be  roved. 

Let  end-1  be  the  end  specified  by  tne  first  word  of  the 
line  buffer,  And  end-2  dc  the  end  specified  by  tne 
second , 

If  end-2  is  tc  oe  moved,  the  second  word  of  the  buffer  is 
replaced  by  tne  vector  fron  end-1  to  tne  selectee 
position. 

If  end-1  is  to  oe  roved,  ther  the  second  word  of  the 
buffer  is  replaced  by  tne  vector  fron  the  selection  to 
end-2,  and  the  first  word  is  replaced  by  the  vector  iron 
the  lover  left  corner  of  the  text  of  tne  statement  to  tne 
selection. 

the  o.-her  vector  editing  commands  are  inclenented  similarly. 
B.  View  Control 

1.  jumps  and  Links 

The  jump  ana  link  machinery  is  used  to  select  statements  to 
be  displayed  at  the  top  cf  the  text-vieving  area  oi  tn* 
screen.  Generally  speaking,  jumps  are  made  within  a  file 
and  links  are  used  either  within  or  between  files.  Jumps 
may  be  made  relative  to  the  structure  of  the  file,  to 
specific  statements,  or  relative  to  the  junp  or  link  ring. 
Links  are  to  a  dynamically  determined  location  in  a 
Particular  user's  file,  and  can  specify  that  display 
parameters  are  to  be  set  when  the  link  ia  taken. 

The  j^mp  ring  represents  the  cnronoloaical  nistory  of  tne 
last  five  jumps  made  within  the  current  file,.  Each  entry 
in  the  ring  contains  tne  P3ID  of  the  display-start 
ptatement  and  a  word  representing  the  display  parameters. 

Tne  link  stack  represents  the  last  few  links  that  have 
been  made,  ana  is  only  updated  if  the  link  is  to  a 
statement  in  another  file,  the  entries  in  this  stack 
contain  the  user's  number,  the  file  name,  the  psic  of  the 
display-start  statement,  and  a  word  representing  the 
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display  parameters. 

Code  written  in  the  contenwnalyaer  SPL  is  used  to  locate 
and  parse  links.  The  four  optional  fields  of  tne  link  arei 

user  name 
file  nme 


location  within  the  file 
display  parameters. 


4  linK'  those  fields  wr.icn  exist  are  delimited  by 

??  which  are  subsequently  used  by  routines  to  effect 

vhe  link. 


.  Sequence  Generator 


J.  °f  routine,  known  a.  the  sequence  generator 

;?»«  2«tS  *  ?'ri  5  1  sequence  of  .tatenentu  atarttne  from  a 
liven  psid  and  governea  sy  the  current  view  paranetera. 

In'r-ll*'},'?*  ce!?er?!'?f  wor*  tre»  A»  “•*«  maintain 
information  controlling  the  sequence.  This  work  area  is 

updated  by  tne  sequence  generator  whenever  it  is  called. 

The  work  area  includes  the  following : 

(1)  P Si*}  of  current  statement 


lcve'1,  nUB,&era  for  statements 
be  included  in  the  sequence 


to 


13)  Current  statement's  level 

(li)  Address  of  statement  Vector  work  Area  (SVWA) 
(5)  Address  of  last  cell  in  SVWA 


6)  Address  of  current  last  ceil  used  in  SVWA. 


If  statement  numbers  are  being  generated,  the  st&teme 
vector  is  generated  for  the  statenent  in  the  svwa 


The  statement  vector  is  a  list  of  words, 
the  level  of  the  statement  and  followed 
containing  the  position  of  the  statement 


starting 
by  entries 
in  the 


with 
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corresponding  clexea. 

For  example,  if  the  statement  vector  contains  (u,l, 5,3,2) 
then  the  statement  is  at  level  four  and  has  statement 
number  lejifc. 

Once  the  work  area  haa  seen  initialized,  the  following 
algorithm  13  used  to  determine  a  candidate  for  tne  next 
statement  m  tne  sequence: 

If  Keyword  reorganization  is  being  used,  then  the  next 
PSID  can  simply  be  retd  from  a  file  block. 

If  a  trail  is  oeirg  followed  and  tne  current  statement 
contains  the  appropriate  trail  marker  followed  Dy  tne 
rare  of  a  statement  in  the  current  file,  then: 

If  the  statement  points  to  itself  then  tne  sequence  is 
terminated  by  returning  a  -1; 

Otherwise  the  PSID  of  the  statement  pointed  to  by  the 
trail  is  returned. 

If  the  current  statement  had  a  substatement  which  is 
within  the  current  level  bounds,  then  its  P3ID  is 
returned. 

If  the  current  statement  has  a  successor  statement  which 
is  within  the  level  bounds,  then  its  PSID  is  returned. 

Otnerwise,  a  *1  is  returned  to  indicate  the  end  of  the 
sequence. 

After  a  candidate  statement  has  been  selected  in  the  apcve 
manner,  it  must  be  checked  against  the  current 
conter.t-ar.alyzer  pattern  if  the  content  analyzer  is  in  use. 
If  tne  analyzer  is  net  being  used,  then  the  candidate  is 
automatically  accepted. 

Flags  in  the  ring  element  for  the  statement  Iruieate 
whether  the  statement  has  beer,  tested  for  the  current 
pattern  and  whether  it  passed 

If  the  statement  has  not  been  tested,  tnen  the  sequence 
generator  calls  the  code  compiled  for  the  oattern  to  make 
the  test.  This  code  is  Jimilir  to  that  described  for  tne 
content-analysis  s?L  in  a  previous  section.  The  general 
il*t  5*  ac<  true  if  the  statement  passes  tne  pattern,  and 
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false  if  it  does  not. 

The  process  of  selecting  candidate  statements  is  continued 
until  (1)  a  statement  u&sses  the  pattern  or  (2)  the  sequence 
is  exhausted. 

One  of  the  primary  uses  of  the  sequence  generator  1*  in 
determining  statements  to  be  displayed, 

3.  Display  parameters 

The  user  has  at  his  disposal  two  types  cf  display 
parameters:  those  which  control  the  selection  processes 
employed  by  the  sequence  generator,  and  those  which  control 
the  format  of  the  display, 

The  formr.t  parameters  control  such  things  as  the 
following: 

(1)  The  number  e'  line*  on  the  screen 

(2)  The  position  of  various  viewing  areas  on  the 
screen 

(3)  The  sixe  of  the  characters 

U)  whether  or  not  the  name,  number,  or  signature  of 
a  statement  is  displayed 

(3)  The  number  of  lines  per  statement  which  are 
displayed 

(6)  Whether  or  not  indenting  is  used  to  indicate  the 
structure  of  the  file 

(7)  Whether  the  file  is  displayed  as  text  or  as  a 
tree  (schematic). 

The  selection  parameters  control  the  following: 

(1)  Whether  content  analysis  is  used 

(2)  Whether  Keyword  reorganization  is  used 

(3)  whether  a  trail  is  lowed 
(kt  Whether  frozen  state,  ents 


^  c 


are  displayed 
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(5)  whether  the  view  is  United  to  only  one  brancn 

(6)  To  what  extent  the  depth  into  the  ring  structure 
is  limited. 

with  the  exception  of  the  display  parameters  wr.ich  control 
such  things  as  character  size  and  location  of  viewing  areas 
on  the  screen,,  the  display  parameters  may  be  modified  at  any 
point  in  the  specification  of  a  command. 

At  certain  points  in  tne  specification  of  some  commands, 
the  user  is  given  the  opportunity  of  changing  tne  disolay 
parameters  as  part  of  the  command.  At  other  tines  the 
user  may  change  them  by  using  Case-3  keyset  characters, 
which  are  not  interpreted  as  part  of  a  command 
specification.  Furthermore,  the  availabilty  of  a  display 
parameter  which  causes  the  display  to  be  regenerated 
allows  the  user  to  treat  the  changing  of  display 
parameters  as  a  pseudo-command.  This  can  ce  done  in  the 
midst  of  specifying  a  normal  NLS  command. 

It.  The  User’s  Content  Analyzer 

The  user's  content  analyzer  is  essentially  a  suoset  of  the 
programmer's  content-analysis  SPL#  rtescrioed  elsewr.er^  in 
tnis  appendix,  it  is  composed  of  two  parts:  a  compiler  and 
the  code  which  is  the  product  of  \\he  compiler. 

The  compiler  is  called  oy  a  user  commune  to  compile 
content-analysis  code  from  a  "pattern*  written  as  text  in 
tne  user's  file  (the  oyr.tax  is  that  of  the 
content-analysis  SFL)  . 

A  display  parameter  then  determines  whether  or  not  the 
sequence  generator  is  to  execute  this  code  for  each  of 
tne  statements  which  have  passeo  all  other  selection 
criteria. 

If  executed,  tne  code  scans  the  givtn  statement 
searching  fer  the  specified  content,  if  the  search  is 
successful,  the  statement  is  displayed;  otherwise,  it 
is  not. 


The  keyword  system  provides  a  rudimentary  forn  of 
information  retrieval  in  NLS.  The  result  of  a  keyword 
search  is  a  list  of  PSir's.  This  list  is  stored  in  the 
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Keyword  file  block.  me  following  apecial 
documenting  the  keyword  system: 


terms  are 


used  in 


tilt  —  Keyword  that  has  oeen  selected  end 
wei  ght 


ha#  nonzero 


reault  <■-*  one  of  the  PSID'ii  generated  by  keyword  EXEC'JTE 
a.  Keyword  File-Block  Format 

The  keyword  data.  consist#  of  two  tables: 


The  first  contains  the  PSlD's  of  hits  and  their 

wei*ntiinWJ'hh  lhC  PSID  in  tr,e  lower  11  Pits  »nd  the 
weignt  in  the  upper  13, 


The  secona  contains  tne  results  of  the  moat 
search  as  an  oraered  list  of  psid's. 


recent 


rS^.Jdfni  WOr<3®  0f  t,he  6l0CK  contain  information 
following  CUrrer‘t  oi  tables,  such  as  the 


(1)  Addreaa  of  start  of  second  table 


(2)  Addreaa  of  item  in  second  table  last 
the  sequence  generator  to  create  difplay 


returned 


by 


(3)  Address  of  last  entry  in  second  table 
U)  Number  of  hitse 


b.  Generation  of  Reaulta 


The  following  algorithm 
reaulta,  given  a  set  cf 


ia  uflec  to  generate  t  list 
selected  keywords. 


of 


A  t&ble  is  built  with  an  entry  for  each  result  vJrn 
entry  taKes  two  words,  the  fi?,t  be^g  the  h^ 

thrfSn^San*:*"111-  T"s  tlble  l*  «enented  in 


tne  specif iea  oy  that 

-.3  searched  for  i  certain  string,  which  is 
currently  set  to  be  an  asterisk  followed  oy  tvo 
eptce*.  This  .-arch  is  done  sy  the 


mu 
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content-analyier  POP  that  does  unanchored  scans. 
If  the  string  is  not  found,  than  the  next  hit  is 
considered  e 


If  the  string  is  found,  the  algoritnm  then  finds 
the  names  in  the  remainder  of  tne  statement.  Each 
name  ia  copied  out  of  tne  text  into  the  statement 
name  register  (SIN) •  The  algorithm  tnen  generates 
the  hash  for  the  name.  This  ia  compared  to  the 
previous  entries  to  see  if  it  already  occurs  in  tne 
table.  If  it  does,  then  tne  score  is  increased  oy 
tne  weight  of  the  current  hit;  otherwise,  a  new 
entry  is  created  with  score  equal  to  tne  weight  of 
this  hit. 

After  tno  entries  nave  ceen  accumulated  in  the 
above  manner,  the  tab^e  1 n  sorted  according  to 
score . 

The  sorted  entries  are  used  to  produce  a  list  cf 
results.  The  results  are  P  ID's,  so  for  the  hash  of 
each  entry,  the  associated  PSIL  must  be  found  by 
searching  the  ring. 


Finally,  the  information  at  the  front  of  the  file 
bloc*  containing  the  results  is  undated  to  show  the 
new  number  of  results. 

This  list  of  PS  ID 1 s  is  usee  •  the  sequence  generator 
when  Keyword  reordering  is  l  .ed  for  by  tne  user. 


6 •  Test  Display 


a.  General 


Tne  collection  of  routines  Known  as  CREATE  DISPLAY  is 
used  to  display  in  the  text  area  of  the  user's  screen 
those  statements  which  are  selected  from  the  current  file 
by  the  sequence  generator. 

The  otatenent  selection  process  and  the  format  of  the 
display  are  under  the  user's  control  by  means  of 
view  specs  and  the  "viewchange"  command, 

CREATE  DISPLAY  is  callea  eacn  time  the  user  modifies  his 
file,  changes  format  parameters,  selects  a  new  candidate 
■titement  for  the  top  of  the  text  area,  cnanres  the 
statement  selection  parameters,  or  explicitly  requests 
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that  the  display  be  recreated. 

A  call  to  CREATE  DISPLAY  does  not  imply  that  the 
entire  entity  win  fie  recreated.  In  net*,  little 
ia  done  as  possible  in  order  to  minimise  file  l/o. 

The  entire  display  i*  reconstructed  from  the 
-inplay»3tart  F3ID  only  in  tne  following  caa»s: 

55s:r«Lv^pir::cT F3ID  <c‘use<i  py 

tun  sntenenn,VOlVini  #trUcturU  elene^s  ^ger 

•3)  Changes  in  format  parameter* 

U*  Explicit  user  command  recreate  display, 

un*  uispiiy  Changes,  the  display  is 

updated  only  for  those  statements  wnico  nave  changed. 

The  display  recreation  is  guided  by  the  format 
aeu»*?r»  ',UI?  **  ’•'"Jncatlon,  and  the  output  of  the 

2utuEt‘?2  r2  p*  l'1,ich  18  Ciliefi  t0  fla<1 1114 

unti*  al  the  -!.?*?!|e?ee  &na  i0r  rUB,e(5uent  statements 

or<2)  thet?Lr  4  1  t,ne  se*'i,‘n'c  «»»  seen  encountered, 
3r  » 2  the  text  area  of  the  screen  is  full, 

h.  Implementation  Details 


following?411  &re"  U,e<i  6y  CBEATE  LI3P1Alf  »™  the 


il)  The  display  list 

(2»  T*i«i  display  Hat  reference  table  (DLRT) 

(3)  The  dl  iplay  buffers. 


The  entries  in  the  display  list  are  used  by  the  disoiav 

bSffeJ1**  have  the  forn  *  vord  count  follove/by^ 
***•  The  axa*l*y  Adware  processes  the 

the  entry.  *e  fcUller  polnt«  «  »X 


Tor  each  line  displayed  in  the  text 
entries  in  the  display  list. 


area. 


there  ^re  two 
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The  first  points  to  a  one-word  buffer  (that  is  cart  of 
the  DLRT  entry  for  that  line)  that  apecifies  the 
position  of  the  start  of  the  line  on  trie  screen. 

The  second  points  to  &  suffer  that  contains  tne  actual 
character  string  that  makes  ud  tne  line. 

For  each  line  tnere  is  a  four-word  entry  in  the  dirt, 
containing  information  sucn  as  the  following i 

(1)  A  T-pointer  for  the  first  character  in  the  line 

(2)  The  first  and  last  column  numbers  containing  text 
in  the  line  (used  in  bu&  selection) 

(3)  The  position  on  the  screen  of  the  left  end  of  tne 
line 

( U )  Flftgo  denoting  sue.,  things  as  the  following: 
ia)  The  line  is  null 

(bj  The  line  contains  special  (nonprinting) 
characters 

(5)  A  copy  of  the  second  display-list  entry  for  the 
line  (used  to  restore  the  display  list  after 
displaying  an  error  menage). 

For  each  PSID  which  is  returned  from  the  sequence 
generator,  a  display  buffer,  DLRT  entries,  and 
display-list  entries  are  created, 

on  the  basis  of  the  above  description,  the  actions  of 
CREATE  DISPLAY  should  be  clear  for  cases  where  the  entire 
text  area  is  being  recreated. 

The  series  of  statements  determined  by  the  sequence 
generator,  starting  from  the  statement  specified  for 
the  display  top,  is  used  to  fill  the  lines  of  the 
display,,  with  the  appropriate  information  being  stored 
in  the  display  list,  DLRT,  and  display  buffers, 

in  the  case  of  text-editing  changes,  the  display  is  only 
partially  recreated j  the  process  is  &s  follows: 

The  DLRT  and  display-list  entries  for  the  statements 
that  were  not  edited  are  copied  to  auxiliary  buffers. 
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If  the  content-analyzer  flag  is  of<*  or  the  ecited 
statement  reuses  the  pattern,  then  u  new  display 
puffer,  DIRT,  and  display-list  entries  are  constructed 
for  it. 

when  this  is  completed,  the  DLRT  and  display  list  are 
replaced  py  the  auxiliary  buffers  and  CREATE  DISPLAY 
returns. 

c.  dug  Selection 

It  is  appropriate  to  consider  the  problem  of  converting 
selections  made  by  the  user  to  valid  character  and 
statement  specifications  at  this  point,  since  oug 
selection  make*  use  of  data  areas  constructed  py  CREATE 
DISPLAY. 

Whenever  input  is  read  from  the  user  work  station,  the 
coordinates  of  the  bug  are  saved  along  with  it.  In  the 
case  whore  the  input  is  meant  &•  a  selection  by  the  user, 
the  coordinate©  must  oe  used  to  identify  a  character  on 
the  screen.  The  DLRT  contains  the  information  required 
to  do  this. 

The  text  area  i»  "homogeneous, "  in  that  each  line 
takes  a  fixed  amount  cf  apace  vertically  and  each 
character  takes  a  fixed  space  horizontally . 

Thus  the  coordinates  of  the  selection  can  be  easily 
converted  to  a  character  ana  line  position  in  the  text 
area. 

This  is  only  part  of  the  problem,  however,  since  the 
selection  may  be  at  a  character  position  that  does  not 
contain  a  character,  in  other  words,  there  are  null 
areas  in  the  text  area  and  selections  in  these  areas 
must  be  "rounded"  to  another  position. 

This  rounding  process  is  done  using  the  information  in 
the  DLRT. 

The  DLRT  has  a  flag  indicating  whether  a  line  is 
null.  These  flags  are  checked  and  the  selection 
moved  up  the  screen  until  it  is  on  a  non-null  line. 

The  DLRT  also  specifies  tn#  first  and  last  columns 
in  the  line  containing  a  character,  on  this  pasis, 
the  selection  is  moved  to  the  left  or  right,  if 
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necessary*  to  put  it  on  a  position  containinf  a 
character. 

It  is  often  the  case  that  bug  selections  must  be 
converted  to  T-pcintere  for  ©aerations  such  as 
editing. 

If  the  line  does  not  contain  any  special  characters, 
which  take  up  more  than  one  character  position  in  the 
SD6,  the  bur  selection  can  ce  converted  into  a 
T-POinter  directly  from  the  information  ir.  the  DLRT. 

There  is  a  flag  in  the  DLRT  which  indicates  whether 
the  lint  contain#  any  special  characters,  and  a 
T-pointer  for  the  first  character  in  the  line. 

If  there  are  no  apecial  characters,  the  character 
count  for  column  k  is  simply  k  greater  than  the 
count  for  the  first  character  and  is  thus 
ootain&bie  from  the  T-pointer  in  the  DLRT  entry. 

If  the  line  does  contain  special  cnaracterc.  then  the 
number  of  special  characters  in  the  line  to  the  left 
of  the  selected  character  must  he  determined.  Rather 
than  store  this  value,  it  is  computed  directly  from 
the  SDb  for  the  statement.  This  amounts  to 
reformatting  the  line  up  tc  the  selected  character, 

C,  Calculator 

The  calculator  gives  the  fits  user  the  ability  to  perform 
arithmetic  operations  using  numbers  selected  from  the  text  or 
entered  from  the  keyboard. 

in  addition,  arithmetic  expressions  (functions)  with  named 
variioles  may  be  evaluated  with  the  aid  of  a  small  compiler 
built  into  i.he  calculator. 

The  calculator  stores  numbers  internally  in  a  fixed-length 
decimal  notation  (currently  using  sixteen  digit®  to  the  left  of 
the  decimal  and  seven  to  the  right) . 

The  arithmetic  routines  work  with  numbers  that  have  been 
"unpacked"  into  an  "accumulator,"  one  digit  to  a  word. 

The  multiplication  algorithm  will  be  briefly  outlined  as  an 
example. 
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The  multiplicand  and  the  product  are  in  unpacxed  form. 

Digits  ere  read  one  at  a  time  from  the  low-order  end  of  the 
multiplier. 

The  multiplicand  is  initially  "aligned"  with  the  low-order 
end  of  the  double-length  partial  product.  During  the  course 
of  the  multiplication,  they  are  realigned  by  "moving"  the 
multiplicand  toward  tne  high-order  end  of  the  product. 

The  first  step  of  the  algorithm  is  to  zero  the  partial 
product. 

Then,  until  all  the  digits  ir  the  multiplier  have  been 
processed,  the  following  algo  ithm  is  repeatedly  executed* 

(1)  Read,  and  convert  to  the  equivalent  oin^ry  number, 
up  to  four  multiplier  digits  nt  a  tine,  thus  forming  a 
composite  multiplier  aigit. 

(2)  For  each  digit  in  the  multiplicand,  multiply  it 
(using  the  hardware  binary  multiplication)  oy  the 
composite  multiplier  digit,  and  add  the  result  to  the 
corresponding  digit  in  the  partial  product. 

This  takes  advantage  of  the  unpacked  form  to  allow 
“digits"  in  the  partial  product  to  take  o',  very  large 
values,  carries  out  of  the  partialr*oroduct  digits  are 
propagated  only  once,  at  the  end  of  tne  algorithm. 

(3)  Realign  the  multiplicand  to  the  left  by  the  number 
of  digits  read  from  the  multiplier. 

Now  propagate  the  carries  in  the  partial  product  to  finish 
the  multiplic iticn. 

The  calculator  contains  a  small  operator-precedence  compiler 
for  arithmetic  expressions. 

The  compiler  produces  noth  code  to  re  interpreted  and  a  symbol 
table  of  the  variables  used  in  the  expression.  The  symbol 
table  grows  toward  higher  addresses,  while  the  code  grows  from 
the  ether  end  of  the  same  block  of  memory. 

When  the  user  asks  to  evaluate  the  expression,  the  program  asxs 
him  to  supply  values  for  the  variables.  The  user  may  fix  a 
variable  to  a  particular  value  and  tell  the  program  not  to 
demand  a  new  value  for  it,  when  til  variables  have  been  giver. 
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valued*  the  code  compiled  for  the  expression  ir  interpreted  and 
the  result  transferred  to  the  "accumulator"  of  the  calculator. 

Tor  each  variable  in  the  expression,  the  symbol  table  contains 
the  following  information: 

(1)  The  name  of  the  variable  Ua  an  A-strlng,  so  that  it 
can  oe  displayed  in  the  command  feedback  line  when  the  user 
is  asked  to  give  it  a  value) 

(2)  The  current  value  of  the  variable 

(3)  Flags  indicating  whether  the  user  should  be  asked  to 
supply  a  value  for  it  when  the  expression  is  evaluated,  and 
if  so  whether  it  has  been  given  a  value  during  the  current 
evaluation., 

The  code  compiled  for  the  expression  is  made  up  of  the 
following  instruction  types: 

(1)  push  values  on  the  stack 

(a)  push  identifier  (specified  by  the  address  of  the 
value  to  oe  pushed; 

(b)  push  constant  (the  value  of  the  constant  follows  the 
instruction  in  the  code) 

(2)  perform  arithmetic  operations  vitn  values  on  top  of 
stack  (unary  minus,  add,  subtract,  multiply,  and  divide; 

(3)  Halt 

The  interpreter  for  the  code  simply  manipulates  tne  stack  and 
calle  the  appropriate  arithmetic  routines. 

D.  processors 

1,  File  Cleanup 

The  file  cleanup  program  serves  to  verify  (and  perhaps  even 
restore,  with  a  bit  of  luck)  the  internal  soundness  of  an 
NLS  file. 

The  program  goes  through  thr  .  llowing  stages: 

(1)  For  each  structure  block: 
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Set  all  the  name  hashes  to  itro. 

Check  the  free  lift  end  mar*  elements  on  the  free  list 
by  getting  their  hashea  to  1, 

Verify  the  used  cell  count  for  the  block* 

(2)  For  each  text  block: 

Check  the  free  space  pointer. 

Check  each  sdb  by  doing  the  following: 

conoare  the  length  given  In  the  first  word  of  the 
header  to  the  character  count. 

Check  that  the  last  character  is  really  an  end 
character. 

Check  that  the  name  character  count  is  reasonable. 

Mark  SDB' s  that  pass  these  tests  by  "0R"ing  360000008 
into  girut  word. 

If  the  SDB  fails  any  of  the  tests,  then  move  the  free 
space  pointer  up  to  that  point  and  jive  ud  on  the  rest 
of  that  block. 

(3)  For  each  graphics  block* 

The  process  is  similar  to  the  process  for  text  blocks. 

At  the  end  of  these  stages  the  entire  file  has  been 
inspected  once.  During  this  a  special  routine  has 
handled  the  loading  of  file  blocks.  If  at  any  time  there 
is  a  "bad*  file  oIock  (i.e.,  one  that  contains  an  error), 
it  tries  to  recover  by  changing  the  type  of  the  block  if 
that  is  in  error  anc.  recalculating  the  checksum  if  that 
is  in  error. 

File  cleanup  now  continues  with  a  second  pass. 

U)  check  the  actual  structure  of  the  ring. 

Start  from  the  origin  and  work  tnrough,  not  trusting 
the  head  and  tail  fl&c«»  Thia  requires  keeping  a 
stack  of  father  PSID’s  jnc  -umpiring  each  successor  to 
the  father. 
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Mark  ring  elements  tnat  are  used  in  tne  structure  by 
setting  their  hashes  to  2  (first  making  sure  that 
their  n^mes  are  zero,  meaning  unused,  and  not  one, 
meaning  on  the  free  list). 

Mark  data  blocks  (both  SDB  and  VD3 )  of  ring  elements 
in  the  structure,  as  used,  uy  changing  the  top  six 
bits  xn  the  first  word  to  3kB  instead  of  36B. 

Correct  errors  in  head  and  tail  flags  if  any  are 
found. 

Errors  in  structure  are  handled  as  follows: 

If  the  Dad  statement  is  the  head  of  a  plex,  then 
that  plex  is  discarded. 

otherwise  the  remainder  of  the  plex  is  discarded. 

This  discarding  is  done  by  linkinc  together  good 
parts  of  the  ring. 

Thus  in  the  first  case  the  father  of  the  bad 
statement  simply  no  longer  has  any  substructure. 

in  the  other  ca*e  the  last  good  member  of  the 
plex  becomes  the  tail  of  the  plex. 

If  a  statement  that  has  valid  structure  his  a  bad  data 
block  associated  with  it,  then  a  dummy  5DE>  is  created 
for  the  statement  and  file  cleanup  continues. 

(5)  Look  for  "lost"  SDB1 s  and  ring  elements. 

Ring  elements  that  still  have  name  hasnes  cf  0  are 
neither  on  the  free  list  or  in  tne  structure.  These 
are  new  put  or.  the  free  list. 

SDB’s  that  still  have  36QCOOOQB  in  their  first  word 
ire  not  pointed  to  by  any  statement.  Th^e  are  now 
marked  aa  garbage. 

Mirks  on  SDB's  are  nov  erased, 

(6)  The  name  hashes  for  all  ring  elements  m  the 
structure  are  now  recomputed. 

This  completes  the  cleanup  of  the  file. 
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2,  File  Compaction 

The  caaic  objective  of  the  file  compactor  is  to  reduce  tne 
number  of  3LB  Mocks  in  a  file  by  combining  the  contents  of 
these  blocks  and  eliminating  resultant  empty  blocks,  in 
audition,  empty  spaces  in  tne  random  file  are  eliminated  oy 
packing  the  file  into  contiguous  blocks.  Structure  blocks 
are  not  compacted. 

SD3  blocks  with  fewer  than  a  fixed  number  of  unused  cells 
are  not  processed  »•  thus  compaction  for  files  which  need 
little  or  no  compacting  will  be  &  relatively  quick 
operation. 

3.  output  Processor 

The  output  Processor  is  used  to  produce  hard  copy  from  NLS 
files.  The  output  of  this  process  includes  formatted  files 
for  a  printer,  a  Dura  typewriter,  and  a  Stromberg-Carlson 
microfilm  machine. 

The  format  of  the  output  is  controlled  cv  means  of 
directives. 

These  are  parameters  for  numerous  variables  such  as  page 
dimensions,  page  numbering,  and  Mon/off  switches"  for  a 
large  set  of  format  options.  The  user  may  control  these 
parameters  ty  means  of  special  strings  of  text  (i.e., 
output-format  commands)  embedded  in  the  file  text.  These 
command  strings,  which  are  also  called  "directives, "  are 
normally  suppressed  from  the  hard-comy  output, 

A  full  set  of  directive  default  v»lue*  for  each  type  of 
device  has  been  established*  these  values  may  be 
overridden  oy  directives  imbedded  in  tne  text  of  the 
file. 

The  Output  Processor  runs  as  a  subproceas  of  NLS  and  has  one 
page  --  a  buffer  -«  in  common  with  it.  This  process,  like 
the  compilers,  utilizes  the  statement-selection  mechanisms 
of  NL3  to  obtain  its  input  data.  Thus  level  clipping, 
content  analysis,  keyword  reordering,  trails,  and  so  forth 
can  be  used  to  control  what  is  output  via  the  output 
Processor, 

k.  compilers 

The  languages  developed  by  ARC  for  internal  use  are 
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